UDC 004.37.01

AH. Zhilyaev ,
Bilişim Enstitüsü ve
bölgesel yönetim sorunları
KBSC RAS, araştırmacı, Nalçik.

giriiş

Birleşik bir bilgi alanının oluşturulması, ister işletme, departman, bölge veya eyalet olsun, çeşitli nesnelerin etkin yönetimi için gerekli bir koşuldur. Birleşik bir ortamın oluşumu, bilgi akışlarının normalleşmesiyle birlikte yönetim süreçlerinin entegrasyonunu içerir. Çoğu zaman, bilgilerin kontrol nesnesinin farklı seviyelerinde ve kısımlarında hareketi, çeşitli bilgi ve muhasebe sistemleri tarafından desteklenir. Buna göre bu sistemlerin entegrasyonuna ihtiyaç vardır. Dünya ekonomisinin artan küreselleşme süreçleri özünde entegrasyon süreçleridir. Bu tür entegrasyon görevleri, Rusya'nın yaklaşan Dünya Ticaret Örgütü'ne (DTÖ) katılımıyla bağlantılı olarak özellikle önemlidir.

Bilgi ve muhasebe sistemlerini entegre etme görevi birbiriyle ilişkili iki bölümden oluşur: veri entegrasyonu ve ardından uygulama entegrasyonu. Veri entegrasyonunu gerçekleştirirken normatif ve referans bilgilerinin (RNI) birleştirilmesi ve standartlaştırılması gerekir. .

Ana veriler, doğrudan IS'de çalışma sürecinde oluşturulan mevcut bilgilerin aksine, bir bilgi sistemindeki (IS) tüm bilgilerin koşullu olarak kalıcı bir parçasıdır. Ana veriler şunları içerir: dizinler, sözlükler, doğrusal ve hiyerarşik listeler, sınıflandırıcılar, kayıtlar, kodlayıcılar, mevcut belgelerin oluşturulmasında kullanılan veriler.

İngilizce literatürde bu tür referans bilgilerini belirtmek için Ana Veri (ana veri, ana veri) terimi kullanılır ve onu yönetme görevlerine Ana Veri Yönetimi (MDM) denir. Bununla birlikte, Rusça'da normatif referans kavramı Bilgi (RNI) artık daha sık kullanılıyor), bilgisayar öncesi zamanlarda bile ekonomik yönetimle ilgili disiplinlerde ortaya çıktı. Bu durumda “normatif” tanımı, dizin oluşturma sorununun endüstri, devlet ve uluslararası standartlar dikkate alınarak çözülmesi gerektiği gerçeğini yansıtmaktadır.

Bugün, örneğin ACS (Otomatik Kontrol Sistemleri) veya IS (Bilgi Sistemleri) gibi terimler aşina hale geldiyse, "SU NSI" (Düzenleyici Referans Bilgi Yönetim Sistemi) kısaltması çoğu zaman kafa karışıklığına neden olur. Kod çözmenin ardında yatan anlam bile çoğu zaman yalnızca uzmanlar tarafından anlaşılmaktadır. NSI yalnızca bir veritabanı değil, aynı zamanda bireysel dizinler ve sınıflandırıcılar arasında birçok çapraz referansın bulunduğu karmaşık bir şekilde organize edilmiş bir sistemdir. Referans bilgilerinin alaka düzeyini korumaya yönelik mekanizma özellikle önemlidir. Referans veri sistemindeki bilgilerin eksiksizliği, doğruluğu ve uygunluğuna ilişkin gereksinimler, geleneksel bir veri tabanından çok daha katıdır, çünkü otomatik kontrol sistemleri de dahil olmak üzere herhangi bir bilgi sisteminin çalışması sırasında, uygulanan görevlerin bilgi içeriği referans verilerine bağlıdır. veri. Ana veriler tüm bilgi sisteminin “temeldir” ve bu sistemin yönetimi merkezileştirilmelidir. Şekil 1'de referans verileri, tüm IS yapısının alt seviyesi olan "bilgi temeli" olarak gösterilmektedir.

Pirinç. 1 Bilgi sistemi seviyeleri

Verilerin birleştirilmesinin, bütünlüğünün, bütünlüğünün ve bileşiminde yer alan tüm referans kitaplarının ve sınıflandırıcıların uygunluğunun korunmasına olanak tanıyan, birleşik düzenlemelere tabi olan ve birleşik bir teknolojik ortam tarafından sağlanan referans veri sisteminin merkezi yönetimidir. Bu nedenle, gerçek sorunları çözen, etkili çalışan bir IS'ye sahip olmak.

Ana veri yönetimi için tam donanımlı yazılımın geliştirilmesi yalnızca birkaç yıl önce başladı. Önde gelen yazılım üreticileri son zamanlarda ana veri yönetimi araçlarına (İngilizce versiyonunda MDM, Ana Veri Yönetimi - ana veri yönetimi) giderek daha fazla önem veriyor.

Referans verilerinin merkezi yönetimi olmadan entegrasyon sorunlarının çözülmesini hayal etmek zordur. Ana veri yönetimi sorunu, banka veya sigorta şirketleri gibi otomatik ve bilgi destekli yapılarda bile ortaya çıkmaktadır. Ana veri yönetimi sistemleri, yalnızca çeşitli entegre bankacılık sistemlerinden veri biriktirmeye, örneğin çeşitli muhasebe sistemleri için raporlar oluşturmaya izin vermekle kalmaz; aynı zamanda referans verilerinin operasyonel yönetimi sorunlarını da çözmek.

Rusya'da GOST'lara benzer referans verilerinin oluşturulması için tek bir merkez yoktur. Ve elektronik teknik belgelerin geliştirilmesi ve dolaşımıyla ilgili yeni yasalar yakın zamanda yürürlüğe girmiş olsa da, durum üzerinde henüz gözle görülür bir etkisi olmadı.

Bölgenin bilgilendirilmesinde NSI'nin rolü

Ülkemizde bilgi teknolojileri sektörüne yönelik kalkınma stratejisinin uygulanmasında bölgesel bilişim önemli bir rol oynamaktadır. Son zamanlarda, Rusya Federasyonu'nun kurucu birimlerinde, bilgi teknolojilerinin bölgesel yaşamın her alanında kullanılmasına yönelik çalışmalar yoğunlaştı. Bu, federal hükümet organları tarafından bir dizi etkinliğin uygulanması ve federal, departman, bölgesel ve belediye düzeylerinde bilgi teknolojilerinin kullanımı alanında düzenleyici belgelerin kabul edilmesiyle kolaylaştırılmıştır. Bölgenin kapsamlı bilgilendirilmesi sorunlarının çözülmesine yardımcı olmak için tasarlanan bu tür belgelerden biri, Rusya Federasyonu Hükümeti Kararnamesi'dir: “Devlet ve belediye hizmetlerinin sağlanmasında temel sınıflandırıcıların, rehberlerin ve kayıtların oluşturulması ve kullanılmasına ilişkin prosedür hakkında Hizmetler elektronik biçimde” 31 Ağustos 2010 tarihli.

Endüstriler ve departmanlar için bilgilendirme programlarına referans verileri için özel bir rol de atanmıştır. Örneğin, 31 Mart 2010'da yayınlandı. Sağlık Hizmetinin Bilişimselleştirilmesi Kavramı taslağında, sağlık alanında bilgi sistemlerinin standartlar ve düzenlemeler dikkate alınarak tasarlanması ve tek bir ana veriye dayanması gerektiği özellikle vurgulanıyor. (Rusya Federasyonu'nun sağlık, sosyal kalkınma ve çalışma ilişkileri alanında kullanılan NSI, toplam 163 farklı sınıflandırıcı ve referans kitabı içermektedir).

Bölgesel düzeyde, otomatik yönetim sistemlerinde ana veri altyapısının uygulanmasının amacı, Rusya Federasyonu'nun kurucu bir kuruluşunun devlet (belediye) bilgi sistemlerinde kullanılan birleşik bir dizin ve sınıflandırıcı sisteminin oluşturulmasının yanı sıra oluşturulmasıdır. bölgesel yönetimin ana hedefleri hakkında sağlanan bilgilerin toplanmasını ve saklanmasını sağlayan temel muhasebe kayıtlarının listesi. Bölgedeki tüm altyapı ve departman bilgi sistemleri için merkezi bir depo ve ortak ana verinin tek tedarikçisi olan ana veri yönetim sistemi, yerel bilgi sistemleri ile konunun “elektronik devlet” uygulamalarının bilgi uyumluluğunu sağlamalıdır.

Açıkçası, Rusya Federasyonu'nda bilgi teknolojisinin geliştirilmesindeki bir sonraki adım, departman, bölgesel ve belediye bilgi sistemlerinin federal düzeyde daha sonra entegrasyonu olmalıdır. Devlet bilgi sistemlerini entegre etme görevi o kadar karmaşıktır ki, belgeleri standartlaştırmanın (örneğin, XML'e dayalı olarak) ve yazılım biçimindeki entegrasyon altyapısının, XML belgelerinin yönlendirilmesinin yanı sıra, veri tanımlarının standartlaştırılması alanında da hükümetin çabalarına ihtiyaç vardır.

Bu alandaki girişimlere bir örnek, Birleşik Krallık'ta benimsenen e-GMS (UK GoverNmeNt Metadata Standard) standardıdır. . Pek çok ülke, bilgi tanımının 15 unsurunu içeren “Dublin Çekirdeği” olarak adlandırılan bilgiyi temel almıştır:

• başlık;
• yazar veya yaratıcı;
• konu ve anahtar kelimeler;
• Tanım;
• Yayımcı;
• diğer katkıda bulunanlar;
• Tarihi;
• kaynak tipi;
• biçim;
• kaynak tanımlayıcı;
• kaynak;
• dil;
• iletişim;
• alan (kapsama);
• hak yönetimi.

"Dublin Çekirdeği", öğelerin kendilerine ek olarak, öğelerin açıklamalarına da sahiptir, örneğin: "Yaratılış tarihi", "Yayın tarihi", "Son kullanma tarihi" vb. Ülkeler yalnızca bu çekirdeği kullanamaz, ancak gerekli gördükleri ek unsurları da ekleyin. Ayrıca bilgi ararken ilk araç genellikle kategorilere göz atmak olur. Bu nedenle, hükümetin meta veri standartları girişimleri, bir kategori listesi (anahtar kelimelerin kullanılmadığı birincil arama aracı) için standartları tanımlamaktadır.

sonuçlar

Devlet ve belediye hizmetlerinin elektronik ortamda sunulmasını düzenlemeyi ve eyalet ve belediye düzeyinde bölümler arası bilgi etkileşimini organize etmeyi amaçlayan mevzuata aşina olduğunuzda şunları görebilirsiniz:

• departmanlar arası bilgi alışverişini sağlamak için gerekli olan devlet bilgi sistemlerinde kullanılan bilgi teknolojilerinin ve yazılımların standardizasyonu için zorunlu gerekliliklerin düzenleyici yasal düzenlemelerde fiilen bulunmaması;
• bölümler arası bilgi alışverişinde kullanılan bilgi sistemlerinin dizinleri, sınıflandırıcıları ve veri şemaları için düzenleyici yasal düzenlemelerde tek tip açık gerekliliklerin bulunmaması;
• tüm federal, bölgesel ve belediye makamları tarafından uygulanması zorunlu olan, elektronik biçimde bilgi sağlamaya ve kamu hizmetlerini sağlamaya yönelik düzenleyici yasal düzenlemelerde bulunmaması. .

Bugün, hem Rusya Federasyonu'nda hem de yurtdışında, eyalet, bölge ve belediye düzeyinde elektronik hizmetlerin sağlanması alanındaki projelerin yanı sıra benzer departmanlar arası projelerin uygulanmasındaki temel zorluk, verileri entegre etmek için önemli çabaların gerekli olduğu koşullardır. ve uygulamalar, belirli belirli teknolojilerin kullanımından değil, ilgili standartların benimsenmesi ve çeşitli organizasyon ve departmanların bilgi teknolojisi mimarilerinin uyumlu hale getirilmesi sürecinin organize edilmesinden oluşur.

Farklı ülkelerin hükümetleri tarafından yürütülen eyalet, bölge, belediye ve departman düzeyinde elektronik hizmetlerin sağlanması alanındaki projeler aşağıdaki ana standart türlerini sağlar:

• veri standartları;
• departmanlar arası bilgi alışverişi standartları;
• meta veri (ve bilgi alma) standartları;
• güvenlik standartları.

Ana verileri korumak için birleşik modern bir metodolojiye ihtiyaç vardır, aksi takdirde veri miktarı arttıkça sistem yönetilemez hale gelecektir.
Referans kitaplarının ve sınıflandırıcıların doldurulmasına ilişkin düzenlemeler ve metodoloji ayrıntılı olarak açıklanmalıdır, aksi takdirde uzmanların referans verilerinin korunmasında yüksek kaliteli ve düzenli çalışmasını sağlamak son derece zor olacaktır. Referans verilerinin kullanıcılarının ve yönetimindeki uzmanların yeterlilik ve sorumluluk alanlarının açık bir şekilde tanımlanmasına ihtiyaç vardır.

Kuvvetler fiziksel ayrılığı imkanı ile çoklu kullanıcı erişim problemini çözen, kullanıcıların uzmanlarla etkileşimini uygulayan ve hem artırılırken sistemin kolay ölçeklendirilmesini sağlayan, yüksek verimli bir modern teknoloji ve referans veri yönetim sistemine ihtiyaç vardır. referans veri tabanının kendisi ve hizmet veren uzmanların sayısı.

Edebiyat:
1. “Rusya Federasyonu'nda bilgi toplumunun geliştirilmesine yönelik strateji” (7 Şubat 2008 tarih ve Pr-212 sayılı Rusya Federasyonu Cumhurbaşkanı tarafından onaylanmıştır);
2. Rusya Federasyonu Hükümeti'nin 31 Ağustos 2010 tarihli "Devlet ve belediye hizmetlerinin elektronik biçimde sağlanmasında temel sınıflandırıcıların, rehberlerin ve kayıtların oluşturulması ve kullanılmasına ilişkin prosedür hakkında" karar taslağı.
3. “NSI İncelemesi”, Ekonomik Kalkınma Bakanlığı Yayını, 2010
4. "2020 yılına kadar olan dönem için sağlıkta bilgi sistemi oluşturma kavramı", 2010.
5. Polotnyuk İ."Entegrasyonun temeli olarak meta veriler", PC Week/RE (492), 2005.
6. Ray Wang, Rob Karel."Trendler 2008: Ana Veri Yönetimi" 2008.

Düzenleme ve Referans Bilgileri- devam eden iş süreçlerine eşlik eden verilerin birleştirilmesi ve normalleştirilmesinin yanı sıra kuruluşun faaliyetlerinin düzenlenmesinin temelini oluşturan kurumsal bilgilerin şartlı olarak kalıcı bir bileşeni. Başka bir deyişle, düzenleyici ve referans bilgiler, bir şirketin dahili olarak oluşturulan ve kural olarak dışarıdan alınan bilgi kaynağıdır. Şirketin faaliyetlerini normalleştiren ve sistematik hale getiren standartları, gereksinimleri, kuralları, düzenlemeleri ve diğer bilgileri içerir.

http://en.wikipedia.org/wiki/Service_Oriented_architecture işletmelerinde ve çeşitli kuruluşlarda meydana gelen iş süreçlerinin çeşitli uygulama sistemlerinin etkileşimini ve birleştirilmesini sağlama gerekliliği, raporlama belgelerinin birleştirilmesi, bir normatif sistem oluşturma ihtiyacına yol açmaktadır. ve referans bilgileri. Normatif referans bilgileri sistemi, tüm Rusya, endüstri ve kurumsal (dahili) [sınıflandırıcılar] ve dizinler üzerine inşa edilen nesne grupları tarafından oluşturulur.

Kurumsal bilgi sistemlerinde referans verilerinin temel sorunları:

• Devlet hizmetleri tarafından geliştirilen ve federal düzeyde onaylanan, düzenli güncelleme ve doğrulama ile güncel bilgi içeriğine yönelik tüm Rusya sınıflandırıcıları ve referans kitapları tam olarak kullanılmamaktadır:
• Sistemlerde kısmen sunulan tüm Rusya sınıflandırıcıları güncellenmez veya normalleştirilmez;
• Birlikte tek bir bütün oluşturan bilgiler, birkaç parçaya bölünerek ayrı dizinlerde toplanır;
• Sistem dizinleri bilgi içeriği ve işlevsel kullanım açısından kopyalanır;
• Dizin verilerinin büyük kısmı normalleştirilmez, normatif ve referans bilgilerin bakımı düzenlenmez, bu da dizinleri güncellerken bilgilerin kopyalanmasına neden olur. Rehber girişlerinde yeterli bilgi yok (girişler tam olarak açıklanmıyor);
• Sistemlerde sunulan sınıflandırıcıların çoğunluğu, bilgi gruplama özelliklerine göre zayıf bir yapıya sahip olup, tek düzeylidir ve bu durum, sınıflandırmanın esnekliği ve bilgi içeriği ile sağlanamamaktadır.

Bilgi sistemi Düzenleme ve Referans Bilgileri.

Kurumsal referans veri sistemi şunları sağlar: depolamak, işleme Ve karşılık sistem kullanıcılarına kalıcı ve koşullu olarak kalıcı bilgiler.

Ana veri sistemleri, kurumsal verilerin güncel tutulması, bütünlüğün sağlanması, hataların ortadan kaldırılması, verilerin bütünlüğünü ve tutarlılığının izlenmesi amacıyla tasarlanmıştır.

Ana veri sisteminde saklanan verilerin ve yapısının değiştirilmesine yalnızca sistem uzmanları tarafından izin verilir. Verileri değiştirmeye yönelik tüm eylemler sıkı bir şekilde düzenlenmiştir. Bilginin kullanıcıları, önceden belirlenmiş arayüzler aracılığıyla veri alan diğer kurumsal bilgi sistemleridir.

Bu yaklaşım, kullanılan bilgi sistemlerinin sayısı ve çeşitliliği ne olursa olsun, işletme içindeki verilerin doğruluğunu sağlar, farklı departmanlar tarafından bilgilerin tekrarlanmasını ortadan kaldırır ve özet raporların oluşturulmasını basitleştirir.

NSI terimi Sovyet kökenlidir, ancak SSCB'de net bir tanım yapılmamıştır. Batı'da, ana verilerin daha uygun bir analogu, özü işlemsel olmayan normalleştirilmiş referans bilgileri (kataloglar) ve sınıflandırıcılar (hiyerarşiler) olan Ana Veri veya Ana Referanslı Veridir. Dolayısıyla Ana Veri, yalnızca ana veri kavramının bir alt kümesi olarak değerlendirilebilir.

Dizin Yönetim Sistemleri, Hizmet Odaklı Mimarinin (SOA) bir parçası olarak değerlendirilebilecek uluslararası Ana Veri Yönetimi (MDM) kavramıyla eşleştirilebilir.

Genellikle ana veri kavramının içinde yer alan sözlüklerin, standartların, kuralların, düzenlemelerin MDM sistemlerinin nesneleri olmaması esastır.

Ayrıca bakınız

• Sabir Asadullayev'in NSI Blogu
• SAP Ana Veri Yönetimi

Bağlantılar

Wikimedia Vakfı. 2010.

Diğer sözlüklerde “NSI”nin ne olduğunu görün:

NSI- bilgilerin yetkisiz toplanması Kaynak: http://www.energosys.ru/?nav=entr&id=6105 NSI düzenleyici referans bilgileri; düzenleyici referans bilgileri yasal. İşaretlemede NSI kask monteli gösterge sistemi...

NSI- düzenleyici referans bilgileri... Rusça kısaltmalar sözlüğü

NSI Bankası- Banka Nevastroyinvest http://nsvbank.ru/​ banka., organizasyon, St. Petersburg ... Kısaltmalar ve kısaltmalar sözlüğü

NSI Runavik Tam adı Nes Sóknar Ítróttarfelag Runavík Kuruluş 1957 Runavik Stadyumu ... Wikipedia

Tam adı Nes Sóknar Ítróttarfelag Runavík 1957'de Runavik Stadyumu kuruldu ... Wikipedia

NSI Runavik Tam adı... Vikipedi

Amca, pl. (birimler Mansi, amca, m. ve f.). RSFSR'nin Hantı-Mansi Özerk Okrugu'nun yerli nüfusunu oluşturan insanlar ve bu insanlarla akraba olan kişiler... Küçük akademik sözlük

Ve grunsha, grusi, neskl., m. ve f... Rusça kelime vurgusu

Mansi, amca, m. ve f. (insanlar) … Rusça kelime vurgusu

EOS NSI- düzenleyici referans bilgilerini yönetmek için birleşik bir endüstri sistemi Kaynak: rosatom.ru ... Kısaltmalar ve kısaltmalar sözlüğü

Kitabın

• Entegre tasarım ve kontrol sistemleri. SCADA. Ders Kitabı, Halim Nazipovich Muzipov, Oleg Nikolaevich Kuzyakov, Sergey Aleksandrovich Khokhrin, Margarita Viktorovna Chashchina, Roman Vasilievich Martynyuk, Eğitim, Sirius-SCADA gerçek zamanlı sisteminin programları hakkında temel bilgileri kapsar. Veritabanları oluşturmaya yönelik "Araştırma Veritabanı Düzenleyicisi" programı anlatılmaktadır... Kategori: Otomasyon. Bilgisayar Mühendisliği Seri: Üniversiteler için ders kitapları. Özel edebiyat Yayıncı: Lan,
• Entegre tasarım ve kontrol sistemleri. SCADA, Muzipov Kh.N. , Rusya Federasyonu üniversitelerinin Urallar Federal Bölgesi UMO Bölge Departmanı tarafından radyo mühendisliği, elektronik, biyomedikal teknoloji ve otomasyon alanında öğrencilere yönelik bir öğretim yardımı olarak eğitim için önerilir... Kategori:

Makine mühendisliği endüstrisindeki işletmelerin verimliliği büyük ölçüde referans bilgileriyle (RNI) çalışmanın ne kadar iyi organize edildiğine bağlıdır. Grubun BT direktörü Oleg Apanasik şu anda AEM-Technologies şirketler grubunda referans veri sisteminin uygulanmasına yönelik proje ve kullanımı hakkında konuşuyor.

Akıllı İşletme: Ana verileri uygularken ana hedefler nelerdi ve bu göreve yönelik çözüm hangi ana aşamalara ayrılabilir?

Oleg Apanasik: Uygulamaya yönelik alınan karar, çalışanlarımızın düzenleyici ve referans bilgileri yönetme konusundaki deneyimlerine dayanmaktadır. Her şey, temel malzeme ve bileşenler rehberinin yönetiminin iki üretim tesisinde ve yönetim şirketinde merkezileştirilmesi ihtiyacıyla başladı. İki kurumsal standart ve birkaç çalışma talimatı geliştirdik, ancak her seferinde bilgi sistemlerinde düzenleyici belgelere uygun olarak girilmemiş materyaller veya mevcut kayıtların kopyaları ortaya çıktı.

Ve 2014 yılı sonunda düzenleyici ve referans bilgilerle çalışmayı optimize etmek için bir proje başlattık. Çerçevesinde, birkaç ana dizin grubunun - “Adlandırma”, “Karşı Taraflar”, “Çalışanlar”, “Finansal” ve “Teknolojik” - normalleştirilmesine ve bunların yönetim yöntemlerine yönelik yöntemler geliştirildi.

Projenin organizasyonel çerçevesi, şirketimizin Kolpino şehrinde bulunan ana işletmesini ve Volgodonsk'tan Petrozavodskmash ve Atommash olmak üzere iki şubeyi içeriyordu.

Proje taslağı, ayrı gruplara ayrılmaya oldukça uygun çok sayıda sistemi içeriyordu.

Her şeyden önce, bir dizi evrensel amaçlı uygulamalı iş sisteminden bahsediyoruz. Bunlar kurumsal kaynak yönetimine yönelik iki çözümdür - SAP ERP ve 1C:UPP ve personel yönetimine yönelik iki çözüm - SAP HR ve 1C:ZUP. Bu aynı zamanda "1C: Belge Akışı", "1C: Konsolidasyon" ürününü temel alan elektronik belge yönetimini ve ayrıca "1C: Mobil İletişim" mobil iletişim giderlerinin muhasebeleştirilmesine yönelik geliştirmeyi de içermelidir. Buna ek olarak devre, üretim faaliyetlerimiz için uzmanlaşmış ürünleri içeriyordu: Üretimin tasarımından ve teknolojik hazırlığından sorumlu TeamCenter (Siemens PLM Yazılımı), işletmenin teknik dokümantasyon arşivinin tutulması ve ürün verilerinin yönetilmesi için bir sistem Intermech şirketinin aranması , aynı üreticiden IMBASE verilerinin veritabanı yönetimi için bir referans ve bilgi sistemi ve erişim kontrolü ve erişim kontrol sistemi Perco. Altyapı ürünleri de dahil edildi: ActiveDirectory etki alanı denetleyicisi ve MS SharePoint kurumsal portalı.

Verilen sorunları çözmek için hangi evrensel bilgi işleme yöntemleri kullanıldı - örneğin veri temizleme, metin arama, hiyerarşik veya başka bir sınıflandırma, veri parametreleştirme veya başka bir şey? Az önce listelediğiniz her şey, önceden kararlaştırılan kurallara uygunluk açısından dizin girişlerinin oluşumunun doğruluğunu kontrol etmenin teknik yöntemleriyle ilgilidir. Burada "kusursuzlaştırma" olarak adlandırılan bir durumdan bahsediyoruz ve ana veri sistemiyle çalışmak için gerekli düzeyde bu, herhangi bir muhasebe sisteminde uygulanabilir. Dizinleri koruma kuralları üzerinde anlaşmaya varmak çok daha zordur. Örneğin isimlendirme için adın düzenleyici belgeye karşılık gelmesi önemlidir ve bu, GOST, OST veya TU'ya göre çalıştığımızda etkilidir. Ancak müşteri, ülkede geçerliliği sona eren standartlara veya yabancılar da dahil olmak üzere üreticilerin kataloglarına göre malzeme kullanmayı isterse, önceden açıklanması gereken tartışmalı konular ortaya çıkar. Bu kurallar dizisi, ana veri yönetimine yönelik yöntem ve standartların temelini oluşturur.

Normatif ve referans bilgilerle çalışmanın metodolojik vurgusunu duymak ilginç olurdu...

Referans veri yönetim sisteminin başarılı bir şekilde çalışması için, bana göre projenin en uzun aşaması olan veri normalleştirmesinin gerçekleştirilmesi önemlidir. Ana işlevi aslında ana veri yönetimi olan ana veri yönetimini (MDM sistemleri) uygulama projesi başlamadan önce, şirket uzun yıllar boyunca çeşitli muhasebe, üretim çözümlerinin yanı sıra büyük miktarda depoladığımız tasarım sistemlerini kullandı. çeşitli referans bilgilerinin miktarı. Ve doğal arzumuz, biriken verileri yeni geliştirilen metodolojiye uygun olarak korumak ve kullanmaktı. Bu amaçla veri normalizasyonu gerekliydi.

Uğruna çabaladığımız ana hedefleri adlandıracağım.

İlk olarak, her dizin girişi ana sınıflandırıcının belirli bir sınıfıyla ilgili olmalı ve bu girişler için bu sınıfın zorunlu özelliklerinin değerleri girilecek şekilde olmalıdır.

İkinci olarak, her kayda birleşik bir ad atanır.

Üçüncüsü, her bir dizin girişinin öznitelik değerleri, onaylanmış yönetim metodolojisine uygun olarak girilir.

Dördüncüsü, dizinde mükerrer girişler olmamalıdır.

Ve son olarak, beşinci olarak, her dizin girişinin, dizine erişen tüm kullanıcılar ve uygulama sistemleri tarafından benzersiz bir şekilde anlaşılan benzersiz bir koda sahip olması gerekir.

Normalleştirme sürecinin kendisi de birkaç aşamaya ayrılmıştır.

Sahnede hazırlık çalışmaları Sınıflandırıcılar yapılandırılır ve “ham” verilerin işlenmesine ilişkin kurallar belirlenir.

Sahnede ham verilerin ön işlenmesi Veri setleri oluşturulur, "ham" veriler uzmanlar arasında dağıtılır, işlenmesine ilişkin kurallar belirlenir ve eğitim tabanları oluşturulur.

“Ham” kayıtların sınıflandırılması iki aşamada gerçekleştirilir: ham kayıt bir sınıfa veya diğerine atanır ve seçilen her sınıf için özelliklerin değeri belirlenir.

Referans kaydının oluşturulması: Sınıflandırmanın ardından, sınıf değerine ve bir dizi karakteristik değere göre bir referans kaydı aranır ve bir kayıt bulunursa "ham" kayıt ona atıfta bulunur. Referans kaydı bulunamazsa, sınıfın ve özelliklerin belirtilen değeri ile oluşturulur.

Abone sisteminde MDM sistemi verilerinin işlenmesi - Bu aşamada abone sistemindeki mevcut ana veri nesnesi kayıtları güncellenir veya yenileri eklenir.

MDM sisteminin kalbinin, referans veri uzmanına akıllı bir asistan olarak hizmet veren Ontology sunucusu (Rus şirketi AXELOT tarafından geliştirilen) olduğunu belirtmek isterim. Sınıflandırma aşamasında, uzmanı belirli bir duruma uygun bir sınıf seçmeye davet eder ve seçilen sınıf için özelliklerin değerlerini önerir.

Ancak entegrasyon veri yolu, MDM kodlarını kullanarak farklı sistemlerdeki nesneleri birbirine bağlayan abone sistemleriyle veri alışverişinden sorumludur.

Büyük makine imalat işletmeleri için referans veri yönetimi sistemi oluşturmanın özellikleri var mı ve bu sistem nelerden oluşuyor?

Bu yapının özelliği işletmenin ölçeğinde değil, şirkette işletilen bilgi sistemlerinin sayısında ve kullanılan referans kitaplarının hacminde yatmaktadır. Üretim türü aynı zamanda sistemle çalışma şeklinizi de etkiler. Ürünlerin tek nüsha halinde üretilmesinden bahsediyorsak, malzeme veya ekipman dizinine seri üretime göre daha sık yeni girişler girilir ve buna göre giriş oluşturma kurallarının sıkı bir şekilde düzenlenmesi gerekir. Şirketimizde her ay yalnızca "Adlandırma" dizinine bine kadar yeni giriş girilmektedir, bu nedenle NSI uzmanlarının materyallerin adlandırılmasının doğruluğunu daha fazla tartışmak için zamanları yoktur.

Bu durumda hangi unsurlar oluşturduğunuz ana veri sistemiyle ilgilidir: malzemeler, araçlar, operasyonlar, personel nitelikleri, tedarikçiler veya diğer bileşenler?

Projemiz, beş gruba ayrılmış bir dizi dizini korumak için bir metodoloji geliştirdi: isimlendirme, karşı taraflar, çalışanlar, finansal ve teknolojik. Bu grupları oluşturan referans kitaplarından bahsedecek olursak, bunlar aslında az önce bahsettiğiniz bileşenleri ve diğer birçok bileşeni anlatıyor. Örneğin “Adlandırma” bölümünde “Temel malzemeler”, “Araçlar”, “Ekipman ve envanter”, “Ürünler” gibi dizinler bulunmaktadır. İlgili gruplarda "Karşı Taraflar", "Çalışanlar", "Personel Pozisyonları", "İş Merkezleri" veya örneğin "Nakit Akış Kalemleri" adı verilen dizinler vardır. Kısacası yirmiden fazla referans kitabımız var ve bunlar AEM Technologies şirketinin finansal, üretim faaliyetleri veya personel yönetimi gibi faaliyetlerinin tüm yönlerini ayrıntılı olarak kapsıyor. Ayrıca isimlendirme dizinleri ile çalışılması durumunda veri kaynağı MDM sistemi, aboneler ise muhasebe sistemleri ve tasarım sistemleridir. Ancak "Çalışanlar" dizini ile çalışırken kaynak, personel yönetim sistemidir ve MDM sistemi, muhasebe sistemleri için bir abone sistemi ve entegrasyon veri yolu rolünü oynar.

Geleneksel olarak, bilgi içerenler de dahil olmak üzere malzeme ve bileşen tedarikçileriyle güçlü ve istikrarlı bağlantılar, büyük makine mühendisliği işletmeleri için önemlidir. Ana veri sisteminin ortaklarınızın benzer sistemleriyle bir şekilde uyumlaştırılmasına ihtiyaç var mı?

Tedarikçi sistemleriyle entegrasyon görevini kendimize koymadık. Ve şirketimizdeki üç tesisteki verileri normalleştirmek için sonuna kadar gitmişken, bunun pek olası olmadığını düşünüyorum. Malzeme beyanında belirtilen kalemin, tedarik için teknik şartnameye dahil edilmesinden sonra, sözleşmenin şartnamesinde yer alması ve ardından teslim alma belgelerinde belirtilmesi ve buna göre depomuza ulaşması bizim için önemlidir. Belirli bir üretim siparişi için iptal edilir. Malzeme listesinin nerede hazırlandığı, satın alma işlemine kimin katıldığı ve üretimin nerede yapıldığına bakılmaksızın, tüm aşamalarda bu tür isimlendirmenin açıkça tanımlanması gerekir.

Referans verileri için BT desteği nedir, buradaki temel işlevler nelerdir ve bunun ürün ve organizasyon açısından nasıl uygulanması tavsiye edilir?

Elbette BT departmanı için yeni bir bilgi sisteminin devreye girmesiyle birlikte onu destekleyecek bir fonksiyon da ekleniyor. Ancak burada yeni bir şey yok: kesintisiz çalışmanın sağlanması, veri yedekleme, kullanıcı eğitimi, düzenlemelerin ve çalışma talimatlarının geliştirilmesi, mevcut işlevselliğin kullanıcı istekleri ve dokümantasyonuna göre değiştirilmesi. Başlangıçta projeye dahil edilmeyen verilerin entegrasyonu bazı zorluklar ortaya çıkarıyor... Ancak burada yüklenicilerimizle yakın çalışıyoruz.

Konunun ürün ve organizasyon yönüne kısaca değinecek olursak, en önemli BT destek ürünümüz 1C:MDM Referans Bilgi Yönetimi ve Axelot Datareon ESB oldu. Axelot ana uygulama ortağıydı.

Şirketin birçok departmanı her zaman bir düzenleyici ve referans bilgi sistemi geliştirmekle ilgilenmektedir. Bu ilgi proje yönetimi yapısında nasıl daha iyi dikkate alınabilir?

NSI uzmanları, MDM sisteminin hem uygulama projesinde hem de sonraki işletiminde özel bir rol oynamaktadır. Projenin başarısı %80 oranında onların sadakatine, çalışma yeteneğine ve mesleki yeterliliklerine bağlıdır. Bilgiyle çalışmanın kurallarını belirleyenler onlardır. Üstelik bunlar çeşitli alanlardan çalışanlardır: “İsimlendirme” ve “Teknolojik” dizin grubu için bu teknik müdürlüktür, “Karşı Taraflar” grubu için - ofis, “Finansal” dizinleri için - muhasebe ve finansörler, “ Çalışanlar” - personel yönetimi müdürlüğü. BT hizmetinin projenin geliştirilmesindeki rolü, gereksinimlerin toplanmasına veya formüle edilmesine yardımcı olmak, toplanan verileri iş sürecindeki tüm katılımcılarla koordine etmek, teknik uygulamayı sağlamak ve dizinlerin bakımı için aracın daha fazla desteklenmesini sağlamaktır. Ancak ana veri yönetimi sürecinin sahibi işletmedir ve bu sürecin gelişip gelişmemesi yalnızca işletme müşterilerine bağlıdır.

Önde gelen Akıllı İşletme uzmanı Sergey Kostyakov, Oleg Apanasik ile konuştu

Sahipler ve yöneticiler, BT sisteminin işletmeye yeni faydalar sağlaması için ERP'yi uygulamaya karar veriyor mu? Rakiplerden birkaç adım önde olmak, basitleştirilmiş yönetim ve artan kar. Bu nedenle, burada BT koşullarındaki pazar geliştirme eğilimleriyle çok az ortak noktası olan terminolojiden alıntı yapmayacağız.

Peki yeni nesil ERP nedir? Bugün bu terim hakkında neyi anlamamız gerekiyor? - Dikkatinizi çekmek istediğimiz şey bu.

2013 yılında Gartner yeni bir terimi tanıttı: " postmodern ERP"Bu, genellikle bir ERP ürünü olarak algıladığımız gibi yekpare bir sistem değil, işletmenin düzeyi ve ihtiyaçları büyüdükçe gelişen ve tamamlanan entegre uygulamalardan oluşan bir bilgi alanıdır. Bu, bir tür bulut hizmetleri, uygulamalar sentezidir. çeşitli platformlarda, yerel sistemlerde vb. işletmenin esnek olmasına, yeni ürünleri hızlı bir şekilde tanıtmasına, biriken verileri uçtan uca süreçlerde kullanmasına, geliştiricilerden gelen en iyi teklifleri hayata geçirmesine, yazılım portföyünü hızlı bir şekilde güncellemesine (hızlı bir şekilde) olanak tanır. “eskiyi” daha gelişmiş bir “yeni” ürünle değiştirmek), yeteneklere ve ihtiyaçlara uygun olarak süreçleri adım adım otomatikleştirmek.

Gartner analistleri, post-modern bir gelişim stratejisine sahip olmayan ancak “monolitik yapıyı” kullanmaya devam eden şirketlerin, sistem karmaşıklık düzeyinde bir artış, maliyetlerde artış yaşayacaklarını ve en önemlisi de bu durumdan kurtulamayacaklarını öngörüyor. entegre dış uygulama setlerini kullanarak yeniden yapılanmaya rakipleri kadar hızlı ayak uydurabilirler.

Yeni nesil ERP'ye dönüşüm, işletmelerin ve BT şirketlerinin şu anda karşı karşıya olduğu zorluktur.

Ne sunabiliriz?

Uygulama, geliştirme ve destek: Uzun vadeli geliştirme stratejinizin bir parçası olarak, entegre bir yeni nesil ERP sisteminin tutarlı, kademeli geçişi ve inşası: modern gereksinimleri karşılayan bir entegrasyon platformunu kullanarak BT mimarinizi adım adım oluşturabileceksiniz. trendleri takip ediyor ve size “bir adım önde” olma fırsatını sunuyor."

IPaaS aracılığıyla entegre edilen harici modül örnekleri:

Bulut ERP

Bulut ERP sistemleri şirketlerin şunları yapmasına olanak tanır:

• İlk geliştirme maliyetlerini azaltmak,
• dağıtım ve ölçeklendirme süresini hızlandırın
• ayarları benzersiz ihtiyaçlarına uyacak şekilde basitleştirin.

Bulut sayesinde işletmeler ERP'nin sadeleştirilmiş bir sürümünü çalıştırabilir; bu da şirketlerin yeni özelliklerden en son düzenlemeleri desteklemeye kadar en son yenilikleri otomatik olarak alması anlamına gelir.

Bulut ERP, işletmeleri geçmişin esnek olmayan ve değişime dirençli ERP'sinden kurtarır. Artık pahalı yükseltmeleri beklemeye gerek yok, riskli yükseltmelere gerek yok. Artık modası geçmiş ERP sistemi yok.

Bulut sağlayıcı güncellemeleri ve güncellemeleri yönetirken BT destek hizmetleri en aza indirilir. Bulut tabanlı bir ERP modeli, verilerin aynı yerde bulunmasını veya başka bir ülkeye taşınmasını çok daha kolay hale getirir.

Ukrayna için ERP 2 belgeleri (beta sürümü)

Resmi belgeler yalnızca yazılım ürününün teslimatı üzerine sağlanır

ERP konsepti ve işlevselliği

Müşteriler

Bugün Ukrayna'da büyük şirketler ERP'yi uyguluyor:

BAS ERP Ukrayna için kullanıcı talimatları

BAS ERP Ukrayna ürününe ilişkin belgeler ve kullanıcı talimatları

ERP Talimatları

ERP belgeleri

ERP için ek modüller

Ana 1C:Enterprise ERP çözümünün işlevselliğini genişleten ek hazır modüller

Dizin « Şirket yapısı"bir işletmenin her türden (idari, üretim vb.) işlevsel bölümlerinin hiyerarşisini içerir.

Dizin herhangi bir hiyerarşi derinliğine sahip olabilir ve bir öğe hiyerarşisi kullanılır. Bu, bir muhasebe biriminin ve planlama nesnesinin hiyerarşideki herhangi bir bölüm olabileceği anlamına gelir.

Bu örnekten, üretimin herhangi bir düzeyde iç içe geçmeyle bölümler (bölümler, sektörler, gruplar, bölümler) halinde yapılandırılabileceği açıktır.

Üretim yönetimi alt sistemi açısından bakıldığında, bölüm, üretim programının aşamalarının yürütücüsü olarak yorumlanır; buna göre, her aşamanın kaynak spesifikasyonlarında, aşamanın yürütücüsü olan bir bölüm tanımlanır.

“Üretim Yönetimi” alt sisteminde değerlerinin belirlenmesi gereken üretim biriminin detaylarını sıralayalım.

• Takvim.“Çalışma Programları” dizininden seçilir.

Bu dizinin bir öğesi çalışma programını - haftanın her günü için ayrı ayrı ve tatil öncesi tüm günler için ayrı ayrı işin başlangıç ​​ve bitiş zamanlarını - tanımlar. Haftanın her günü için, programa göre işin başlangıç ​​ve bitiş zamanını ayrı ayrı belirleyebilirsiniz ve haftanın her günü için birkaç çalışma süresi olabilir, örneğin 8.00 - 13.00 ve 14.00 - 18.00. . Üretim programı hesaplama prosedürünün her takvim günü için departmanda mevcut çalışma saati sayısını belirleyebilmesi için bir departmanın çalışma programı gereklidir.

• Malzeme deposu. Departmanda planlanan aşamalar için üretim programına göre malzeme ihtiyacının oluşturulduğu depo. Bu depo, aşamayı tamamlamak için malzemelerin kullanılabilirliğini kontrol eder. Gerekirse malzemenin isimlendirilmesi ve özellikleri için, stoklarının kontrol edileceği ayrı malzeme depoları oluşturabilirsiniz.
• Planlama aralığı. Aşamalara göre üretim programı hesaplanırken departman için hangi aralığın kullanılacağını belirler. Seçenekler: "Gün", "Hafta", "Ay".

Gerekirse "seçeneği Saat", bu aralığı kullanmak için ilgili işlevsel seçeneği etkinleştirmeniz gerekir.

Bir departman için planlama aralığı seçme kriterleri, departmanda gerçekleştirilen tipik aşamaların süresine ve aralığın süresine uygunluktur. Örneğin bir departmandaki aşamaların çoğu birkaç günden fazla sürmüyorsa “Gün” aralığını kullanmak mantıklıdır. Bir aşamanın tipik süresi bir haftayı önemli ölçüde aşarsa, "hafta" aralığını kullanmak mantıklı olacaktır.

Aralığın uzunluğunun gerekli olanın ötesinde arttırılması, üretim süresinde gözle görülür bir artışa, yani üretim programının zaman içinde "uzatılmasına" yol açar.

Aralık uzunluğunun aşırı derecede azaltılması, üretim programında çok fazla zaman ayrıntısına yol açar ve bu da yerel sevk görevlisinin işini zorlaştırabilir.

• Rota sayfalarını yönetme yöntemi. Bu ayar, departmanda yürütülen Rota Sayfalarını yönetirken kullanılır.

Seçenekler:

• "BBV/UBVV Metodolojisi". ML yürütme programı, anahtar RC'ler için oluşturulur; ML yürütme, ön ve son arabelleğin ML tarafından geçişiyle izlenir.
• "Operasyonel planlama". Zamanlama, tüm DC'ler ve rota sayfası işlemleri için oluşturulur. Ek olarak, açıklamanız gerekir "Planlama Yöntemi"– “İleri” veya “Geri”.

Depolar (depo alanları)

Üretim planlaması açısından depo, üretim bölümlerinin malzeme ve yarı mamul ürünlerle ilgili ihtiyaçlarını karşılayan üretim sisteminin bir nesnesidir.

Program hesaplanırken, depolarda malzeme ve yarı mamul ürünler için bir ihtiyaç programı oluşturulur (ürün, özellikler, miktar, planlama aralığı).

Üretim biriminin varsayılan olarak "güç aldığı" depo, birim ayrıntılarına göre belirlenir.

Ancak bunun tersi geçerli değildir: "Depo" dizinindeki "Bölüm" özelliği planlamayı etkilemez (ve muhasebe amaçlarına hizmet eder).

Tedarik deposunun daha ayrıntılı bir tanımını (bölüm ve kalem için, kaynak bileşenin özellikleri) belirleyebilirsiniz.

Tugaylar ve tugay bileşimi

Ekip, atölyedeki aşamada (operasyonlarda) işin doğrudan yürütücüsüdür. Rota Sayfasına göre çalışanların çıktısını hesaba katmak için yerel sevk görevlisi, ekibi ve ekibin Rota Sayfasına göre gerçekleştirdiği iş türlerini belirttiği bir "Tugay Düzeni" belgesi oluşturur.

Ekip çalışanlardan oluşmaktadır. Tugayın bileşimi “belge ile belirlenir” Tugay kompozisyonunun oluşumu" ve belgede belirtilen tarihten itibaren geçerlidir.

Siparişlerin bireysel çalışanlara göre detaylandırılması gerekiyorsa “Tugaylar” dizininde bir çalışandan oluşan tugaylar oluşturulur.

İş merkezi türleri, iş merkezleri

İş merkezi türleri, bir departmanın üretim kapasitesini tanımlamayı amaçlamaktadır. İş merkezi türleri, üretim programını hesaplarken üretim aşamalarını aralıklara atarken doldurulan, planlama aralıklarında kullanılabilir bir çalışma süresi fonuna sahiptir.

Bir iş merkezi görünümü, ekipman parçaları gibi belirli iş merkezlerinden oluşur. İş merkezlerinin eşanlamlısı “Birbiriyle değiştirilebilir iş merkezleri grubu”dur.

İş merkezlerine örnekler:

■ Ekipman birimi

■ İş yeri

■ Bir grup işçi (ekip veya profesyonel birlik).

■ Çalışan

■ Ekipman ünitesi

Maksimum üretim hacmine karşılık gelen uygun bir üretim programını hesaplamak için, kaynak belirleme aşamaları için her departmanda, aşamanın verimini sınırlayabilecek yüklenebilir türde iş merkezlerinin tahsis edilmesi gerekir.

İş merkezlerinin türlerine ilişkin ayrıntılar aşağıdaki gibidir:

• “Plan çalışması” bayrağı. Bayrak etkinleştirilirse bu tip RC, aşamada yüklü RC tipi olarak seçilebilir. Bayrak, bölümün "darboğazına" dönüşebilecek bölümün RC türleri için açıktır.
• Maksimum kullanılabilirlik (saat, dakika, saniye). RC tipinin ait olduğu bölüm aralığında bir aşamadaki bir partinin maksimum işlem süresini belirler. Bir aşamanın bir partisi için, maksimum kullanılabilirlikten daha büyük bir aralıkta işlem süresi atanamaz.

UP2'nin mevcut sürümünde, RC türlerinin ayarları, açıklanan özü korurken zaten bir miktar değişti. Artık onay kutularını aşağıdakileri yapmak için kullanabilirsiniz:

• Üst düzeydeki planlamada RC zamanının mevcudiyeti dikkate alınmalı mıdır? Ve eğer öyleyse, bu DC indirilebilir olacak mı, indirilmeyecek mi?
• DC, daha düşük düzeyde Rota Sayfalarını kullanarak üretim yönetimine dahil olmalı mı?

Aşağıdaki şemada “Kurumsal Yapı”, “İş Merkezi Türleri”, “İş Merkezleri” dizinlerinin yapısı ve ilişkisi gösterilmektedir.

Kullanılabilir iş merkezi saatinin girilmesi

İş merkezlerinin kullanılabilir zaman fonunu aralıklarla girmek için “İş merkezlerinin kullanılabilirliği” belgesini kullanın. Belge başlığında departmanı, iş merkezi türünü ve belge dönemini seçin.

Belgenin tablolu kısmı, belge dönemindeki sütunlar - bölüm aralıkları (örneğin günler) ile genişletilir.

Tablo bölümünün satırında İş Merkezi Türüne ait bir iş merkezi seçmeniz ve sütun aralıklarına göre her aralık için kullanılabilir saat sayısını belirtmeniz gerekir.

Kaynak Özellikleri

Ağ diyagramı olarak kaynak belirtimi

Çeşitli spesifikasyon türleri bilinmektedir; örneğin tasarım spesifikasyonları, rotaların operasyonel akış şemaları, bir parçanın departmanlardan geçiş rotaları olarak "antrenmanlar".

Herhangi bir ürünün üretim sürecini tanımlamanın en yaygın yolu bir ağ şemasıdır.

Kaynak Belirtimi Bir ürünün üretimi için ağ programını açıklar.

Ağ düğümleri Böyle bir açıklamada, bir ürünün veya yarı mamulün imalat sürecindeki bölümler tarafından sıralı veya paralel olarak gerçekleştirilen, birbirine bağlı üretim aşamaları yer alır. Bir departmanda - gerçekleştirilecek bir veya daha fazla aşama.

Yaylar– aşamalar arasındaki karşılıklı bağımlılık, hangi aşamaların tamamlanmasının ardından sonraki aşamaların başlayabileceğini gösterin.

Herhangi bir üretim sürecini (ayrık, sürekli üretimde, inşaatta, tasarım faaliyetlerinde) tanımlamak için bir ağ şeması kullanmak uygundur.

Genel olarak bir ağ şeması, yalnızca departmanlar arasında ürün aktarımına ilişkin gerçekleri değil, aynı zamanda iş sonuçlarının aktarımına ilişkin gerçekleri de içerebilir.

Atölyeler arasında aktarılan işin sonucunun mutlaka maddi bir ifadeye sahip olması gerekmez. Bir sonucun bir departmandan başka bir departmana aktarılması ve böylece diğer departmanın işin kendi payına düşen kısmını yapması, mutlaka belirli ürünlerin transferini gerektirmez. Ürün örneğin bir departmana yerleştirilebilir veya gerektiğinde taşınabilir, ürün üzerindeki çalışmalar ise diğer departmanlar tarafından gerçekleştirilebilir.

Üretim aşamaları yalnızca ürünlerin imalatını değil aynı zamanda üretim hazırlığı, ekipman kurulumu, dokümantasyon geliştirme, eğitim, kurulum vb.'yi de içerebilir.

En uç durumda, bir kaynak spesifikasyonu, ürün yapısının hiyerarşik ağacına uygun olarak bir ürünün imalatının tüm aşamalarını içerebilir. En basit durumda bir kaynak spesifikasyonu bir üretim adımından oluşur. Bu kaynak spesifikasyonuna tek aşamalı denir.

Düğüm aşamalarına sahip bir ağ diyagramı olarak kaynak spesifikasyonunun bir örneği aşağıdaki diyagramda gösterilmektedir:

Kaynak Belirtimi Yapısı

Bir kaynak spesifikasyonunun konfigürasyon nesnesi olarak yapısı aşağıdaki diyagramda gösterilmektedir:

Kaynak spesifikasyonu şunları içerir:

■ çıktıların listesi,

■ malzeme girdilerinin listesi,

■ işçilik maliyetlerinin listesi (iş türüne göre),

Çok aşamalı bir kaynak spesifikasyonunda her girdi, çıktı ve emek girdisi için girdinin (emek girdisinin) tüketildiği veya çıktının üretildiği aşamanın belirtilmesi gerekir.

Aşamaların girdilerinde, üretim sürecine dışarıdan gelen, şartnamede tanımlanan başlangıç ​​bileşenleri (malzemeler, hizmetler) belirtilmektedir.

Yani bunlar, belirli bir aşama için aynı spesifikasyonun diğer aşamalarının çıktıları olmayan bileşenlerdir.

Malzeme girişi için - yarı mamul bir ürün, bayrağı etkinleştirebilirsiniz " Proseste üretilen» ve buna göre bu yarı mamul ürünün üretilmesi gereken Kaynak spesifikasyonunu seçin. Sonuç olarak, bu kaynak spesifikasyonu, bu girdiden başka bir kaynak spesifikasyonu tarafından "aşağı" "tamamlanacaktır". Böylece, bireysel spesifikasyonlardan, bir spesifikasyonlar dizisi şeklinde, bitmiş ürünlerden oluşan eksiksiz bir ağaç oluşturmak mümkündür.

Bu spesifikasyon kademesi, belirli bir üretim siparişi satırı için bir spesifikasyon oluşturulurken kullanılır. İlgili kaynak ürün reçetelerinin tüm kademesi, sipariş satırı ürün reçetesine kopyalanır.

Sahne donanımı içinde " Aşamalar arasında optimum miktarda transfer» Aşamalar arasında aktarılması tavsiye edilen ürün partisinin (iş sonucu) miktarını belirtebilirsiniz. Üretim programı hesaplanırken aşama miktarı parti verilerine bölünür ve yüklenen DC türlerinin kullanılabilirlik süresine göre her parti ayrı ayrı planlanır.

Kaynak spesifikasyonunda ve rota haritalarının teknolojik operasyonlarında standart emek yoğunluğu “bölümde belirtilmiştir” İş türleri».

İş türü - işçiler için işgücü fiyatlarının girildiği ve işçilerin çıktısının dikkate alındığı analitik. İşin türünün adı, işin tanımına ek olarak, gerekli işçi kategorisini ve mesleklerini de içerebilir. Bir iş türü için ölçü birimi, örneğin saat veya adet olarak belirtilir. ürünler.

Periyodik bilgi kaydındaki her çalışma türü için " Fiyat:% s» İşin cinsine göre güncel birim fiyatı belirtebilirsiniz.

Kaynak Belirleme Aşamaları

Bir kaynak spesifikasyonu tek aşamalı veya çok aşamalı olabilir.

Spesifikasyon tek aşamalı ise tek aşamanın detayları doğrudan spesifikasyon formunda düzenlenir. Spesifikasyon çok aşamalıysa, spesifikasyon bir aşama listesi içerir. Aşama detaylarını düzenlemek için aşama listesinden ayrı bir aşama formu açmanız gerekmektedir.

Aşamaların sırası aşama detaylarına göre belirlenir: “Aşama numarası”, “Sonraki aşama numarası”. Aşama numarasına ve bir sonraki aşamanın sayısına bağlı olarak aşamalar arasındaki bağlantılar, aşamaların ağ diyagramı şeklinde oluşturulur.

Sahne ayrıntıları, sahne planlamasının ana parametrelerini belirler:

• Alt bölüm, sahnenin gerçekleştirildiği yer. Bir aşama için yalnızca bir bölüm tanımlanır. Aynı aşamalar farklı departmanlarda gerçekleştirilebiliyorsa farklı kaynak spesifikasyonları oluşturmak gerekir.
• Bir defada üretilen miktar. R Aşama tamamlama süresinin standartlaştırıldığı parti büyüklüğü veya iş hacmi. Örneğin, özellikte bir birim belirtilirse aşama yürütme süresi bire normalleştirilir.
• "DC türlerinin çalışmasını planlayın" ile ilgili bayrak. Aşamanın süresini normalleştirme yöntemini belirler.
  • Bayrak etkinleştirildi. Aşamada, aşamaya göre hangi tür iş merkezlerinin yükleneceğinin ve eş zamanlı olarak üretilen miktarın yüklenen iş merkezi türü üzerinde işlenme süresinin belirtilmesi gerekmektedir. Bu tür DC'ler, üretim programını yerine getirirken "darboğaz" haline gelebilir, dolayısıyla programdaki yükleri hesaplanır. Ayrıca ön (yüklü RC görünümünde işlenmeden önce) ve son arabellek süresinin belirtilmesi gerekir. Tamponlar üretim programında ayrı aralıkları işgal eder. RC'nin yükleme tipinden önceki veya sonraki işlem süresinin aralığın süresinden çok daha az olması durumunda, tampon sürelerinin belirtilmesinin, tüm aralıkların tamponlar tarafından haksız bir şekilde yakalanmasına ve buna bağlı olarak, zaman aralığının haksız bir şekilde artmasına yol açabileceğini hatırlayalım. Üretim programında bir aşamanın süresi.
  • Bayrak kapalı. Aşama, herhangi bir parti miktarı için tamamlanması gereken süreyi gösterir. Bu süre zarfında etaptaki sayı ne olursa olsun etabın her halükarda tamamlanacağına inanılıyor. Bayrak, yürütülmesi yüklü RC türlerinde (“darboğazlar” olarak adlandırılan) işlemle ilgili olmayan aşamalar halinde kapatılabilir; buna göre, böyle bir aşamayı gerçekleştirirken departmanın (göreceli) olduğu kabul edilir. “Darboğazları olan” departmanlara) sınırsız üretim kapasitesi.
• Bayrak « Sürekli» aşama, aşama uygulamasının programda bitişik olmayan birkaç aralığa bölünüp bölünemeyeceğini belirler.
  • Bayrak açıksa, aşama sürekli olarak yürütülür ve programda yalnızca bitişik aralıklarla yerleştirilebilir.
  • Bayrak kapatılırsa, aşamanın yürütülmesi kesintiye uğrayabilir, yani zaman aşamasının bir kısmı programda bir aralıkta ve bir kısmı da birinci aralığa bitişik olmayan başka bir aralıkta yerleştirilebilir.

Süreklilik kriteri: Bir aşamadaki en az bir işlem süreklidir ve aralığın süresiyle karşılaştırılabilir. Bu işlemler arasında örneğin ısıl işlem, boyama, kurutma vb. yer alır.

"Sürekli olmayan" ve "sürekli" aşamaların planlanması arasındaki fark aşağıdaki diyagramda gösterilmektedir.