Açık Döngü Süreçleri İş Hayatında Bilgi Akışını Nasıl Bozuyor?

Kariyerim boyunca oldukça fazla iş süreci mühendisliği yaptım ve bulduğum en büyük sorun her zaman aynı: açık döngü iş süreçleri. Açık döngü süreçleri çoğunlukla sorumluluğun birden çok kişiye ve çoğu zaman birden çok departmana bölünmesi nedeniyle oluşur. Ar-Ge'de yeni bir ekipman talebiyle başlayan bir bilgi akışı, organizasyonel sınırların dışına çıkmadan önce Finans ve Satın Alma'dan geçebilir (sırasıyla birkaç departmandan geçecektir) ve sonunda Kabul Etme ve Satın Alma'ya geri dönebilir. , şans eseri akışı başlatan Ar-Ge grubu.

Her adımda iletişimin kesintiye uğrama olasılığı vardır ve proje yöneticilerinin bu riskleri azaltması gerekir. Bir iş sürecinde yerleşik olan bilgi akışları, herhangi bir istisnayı yakalayacak ve ardından ele alacak şekilde açıkça yapılandırılmamışsa, başarısızlık çok sonraya kadar tespit edilmeyecek veya belki de hiç tespit edilmeyecektir. Bazı bilgi akışı başarısızlıkları yalnızca nispeten önemsiz öğelerin doğru bir şekilde sipariş edilmemesine veya teslim edilmemesine neden olurken, diğer arızalar kuruluşlara büyük miktarda paraya mal olabilir veya kritik görev faaliyetlerinde gecikmelere neden olabilir.

Açık Döngüler Milyonlarca Dolara Mal Olabilir

Konuyu açıklamak için önce, artık izini süremediği yüz milyonlarca dolarlık ekipman için vergi ödeyen ve bu gereksiz masrafı kaldırmak isteyen büyük bir ilaç organizasyonundan bahsedeceğim. Projemiz, her biri yılda on milyonlarca dolar gereksiz vergi ekleyen ve aynı şeyleri yanlışlıkla birden çok kez sipariş etmek için harcanan paranın çok daha fazlasının eklendiği birçok temel süreç kusurunu ortaya çıkardı.

Sorumluluk Alanları Arası Tek Yönlü İletişim

Tüm büyük organizasyonlar gibi sorumluluklar da silolardaydı. İmalat sektöründeki birinin X ekipmanına ihtiyacı vardır, bu nedenle Finans'ı bilgilendirir ve bir satınalma siparişi (PO) oluşturulur. Sipariş, PO'yu satıcıya gönderir. İleride bir yıla kadar X, Alıcı tarafından teslim edilir ve kabul edilir. Alma, İmalat ve Finansmanı bilgilendirir. Finans, bir varlık etiketi yayınlar ve bu, Alma'nın X'e tokat attığı bir şeydir. X, üretim hattına yerleştirilir ve her şey yolundadır.

Bunun dışında her şey yolunda değil. Başlangıç ​​olarak, çalışanlar gelir ve gider ve aynı roldeki başka birinin dokuz ay önce X sipariş ettiğini fark etmeden X sipariş etmek kolaydır. Finansın bu siparişin bir kopyası olduğu hakkında hiçbir fikri yok: Sadece başka bir X'e ihtiyacınız olduğunu varsayıyorlar ve bu nedenle başka bir PO oluşturulur ve başka bir sipariş verilir. Bunun dışında, yanlışlıkla fazla sipariş vermeseniz bile, sahip olduklarınızın izini hızla kaybedersiniz.

X'in karmaşık bir ekipman parçası, belki de bir doldurma-bitiş çizgisi olduğunu varsayalım. Görev ömrü boyunca tümü birden çok kez değiştirilecek olan 20 ana bileşenden oluşur. X'in bir parçasına gelişigüzel bir şekilde yapıştırılan bir varlık etiketi, aşınma ve yıpranma nedeniyle kaybolacaktır. Daha da kötüsü, zamanında Alma'ya ulaşmadığı için varlık etiketi uygulanmayabilir. Bundan sonra, hiç kimsenin X'i nasıl takip edeceğine dair bir fikri yok ve bu nedenle kullanım ömrü sonunda nasıl devre dışı bırakılacağı hakkında hiçbir fikri yok. Vergi açısından X, hala işleyen vergilendirilebilir bir kalemdir.

20 yılı aşkın bir süre boyunca, bu, alt çizgiyi önemsiz olmayan bir şekilde incitmeye başlayacaktı. Ayrıca, Finans, ERP sisteminin bir bölümünü bir varlık tanımlayıcı grubuyla kullanırken İmalat, farklı bir varlık tanımlayıcı grubuyla tamamen ayrı bir ERP modülü kullanıyor. Yıl sonunda, hiç kimse iki sayı grubunu uzlaştıramaz ve denetçiler, sermaye ekipmanınızla ilgili neden onlarca veya yüz milyonlarca dolarlık tutarsızlığınız olduğunu sorguluyor.

Bunlar, bir dizi açık döngü iş sürecinden kaynaklanan klasik problemlerdir. Açık döngü, süreç akış çizgisi boyunca açık onay noktaları oluşturmadığınız zamandır. Yukarıdaki örnekte, başarısızlığın garanti edildiği çok sayıda açık döngü süreci vardı.

İki Yönlü Bilgi Akışları Oluşturma

Sorunu şu şekilde çözdük. Baştan sona her önemli süreç akışını modelledik. Tüm açık döngüleri belirledik. Ardından, en baştan başlayarak bu döngüleri tek tek kapatmak için basit yollar geliştirdik.

Adım bir

Üretimin X'e ihtiyacı var, bu yüzden Finans'tan bir PO açmasını istiyorlar. Finance şimdi onaylamak için İmalat ile kontrol ediyor ve 24 ay geriye giden X için önceki siparişlerin ayrıntılarını sağlıyor. Siparişlerin yanlışlıkla tekrarlanması önlenir.

İkinci adım

İmalat, Finance'e, hizmet ömrü boyunca değiştirilecek olan X bileşenlerinin bir dökümünü sağlar. Finans, her bileşen için varlık etiketleri oluşturur ve İmalat ile onaylar. Her iki ERP modülü de bileşen başına eşleşen varlık etiketleri ile doldurulur ve varlık yaşam döngüsü boyunca izlemeye izin verir.

Adım üç

Alma, İmalatı bildiren Finance'i bilgilendirir. Varlık etiketlerinin yerleştirilmesi, her bir etiketin doğru bileşenine yerleştirildiğinden emin olmak için İmalattan sorumlu bir taraf tarafından yapılır. Tüm etiketler/bileşenler daha sonra iki ERP modülü için yeniden onaylanır.

Adım dört

Bir bileşen her değiştirildiğinde, İmalat Finans'ı bilgilendirir ve bu bileşen için yeni bir varlık etiketi oluşturulur ve İmalat tarafından yeni bileşene yerleştirilir ve ardından her iki ERP modülünde onaylanır. Daha sonra Finans, eski bileşeni kitaplardan kaldırma sürecini başlatırken İmalat, İyi Uygulama Kılavuzu (GMP) hizmetten çıkarma sürecinden geçer. Hizmetten çıkarmanın sonunda İmalat, varlığın kayıtlardan çıkarılabilmesi için Finans'ı bilgilendirir.

Ayrıntılar, bu basitleştirilmiş örneğe göre biraz daha karmaşık, ancak konu açık: Yol boyunca her aşamada açık kontroller ve onaylar var.

Acil Durum Eylemlerinin Sağlanması

Başka bir projede, bir hizmet şirketinin müşteri memnuniyet oranlarını iyileştirmesine yardım etmem istendi. İşleri tamamen taleplerin işlenmesiyle ilgiliydi ve teklifleri alamamaktan endişe duyuyorlardı. Ayrıca, kazanan tekliflerinde, müteakip müşterilerden gelen memnuniyetsizlik, kayıp hesap oranlarının çok yüksek olduğu anlamına geliyordu.

Bir kez daha açık döngü süreçleri olan sorunun özünü belirlemek sadece birkaç gün sürdü. Bir potansiyel müşteri bir teklif istediğinde, hesap yöneticisi, teklifi oluşturmaktan sorumlu kişiye bir müşteri gereksinimleri taslağı göndermek için kendi iç sistemlerini kullanırdı. Teklifi oluşturan kişi daha sonra teklifi oluşturacak ve müşteriye iletecektir. Umuyoruz ki, müşteri sonunda genellikle istenen değişikliklerle yanıt verir ve teklif oluşturucu bunları bir sonraki sürüme ekler. Bir noktada, müşteri teklifi kabul edecek ve Muhasebe tarafından yeni bir müşteri hesabı oluşturulacak, bir fatura kesilecek ve işe alım ekibi bilgilendirilecektir.

İlk sorun, teklifi oluşturandan hesap yöneticisine açık bir onay gelmemesiydi, bu nedenle bazen teklifler zamanında oluşturulamıyor ve gönderilmiyor ve kimsenin bundan haberi olmuyordu. Bu mümkün oldu, çünkü dahili sistemde bir teklif için son tarih gösterecek bir alan yoktu ve teklifi oluşturan kişi sürekli olarak fazla çalıştığından, bu durum tekliflerin çok geç sunulmasına neden oldu. İşletmedeki zayıf bilgi akışı nedeniyle bu durumlar hiçbir zaman su yüzüne çıkmadı.

Bunu takiben, teklifte yapılan değişiklikler hesap yöneticisine iletilmedi. Bu önemliydi, çünkü bir müşteri nihayet noktalı çizgiyi imzaladığında işe alım ekibine bilgi veren hesap yöneticisiydi. Genellikle özet, müşterinin gerçekten kabul ettiği tekliften ziyade hesap yöneticisinin ilk anlayışına dayanıyordu.

Sözleşme başladıktan sonra, müşteri belgeleri gelecek ve o hafta işleme havuzunda bu işlerle ilgilenmek üzere görevlendirilen ekip üyesine iletilecektir. Açık bir alındı ​​onayı olmadığı için, müşteri, işleme çalışmasının sonuçlarını neden almadığını sormaya başlayana kadar, hiç kimsenin haberi olmadan belgelerin kaybolması mümkündü.

İşlenmiş belgeler müşteriye geri gönderildiğinde, alındığına dair bir onay yoktu, bu nedenle herhangi bir eksik belge, bir yerlerden biri onların yokluğundan şikayet etmeye başlayana kadar gözden kayboldu.

Önemli Olayları Onaylayın

Teklif verme sürecinin her adımında açık onaylar oluşturduk. Sistem eksiklikleri için geçici çözümler oluşturduk, böylece gerekli olan tarih ve müteakip teklif değişiklikleri de dahil olmak üzere tüm kritik bilgiler alındı. Şirket içindeki ve şirket ile müşteri arasındaki tüm bilgi akışı için açık kontroller ve onaylar uyguladık.

Örneğin, bir müşteri bir belge paketi gönderdiğinde, artık müşteri hesap yöneticisine onları bilgilendiren bir e-posta gönderecekti. Müşteri hesap yöneticisi, bunu talep işleme sürecinde sorumlu tarafa iletir. Belgeler üç gün içinde alınmazsa, bir uyarı verilir. Belgeler alındığında, müşteriye alındığına dair bir e-posta gönderildi. Şirket, işlenmiş belgeleri müşteriye geri gönderdiğinde de bunun tersi geçerliydi.

Çoğu müşteri, basılı belgeleri ileri geri karıştırmak için ABD postasını kullandığından, her adımda açık kontroller kullanan kapalı döngü süreçleri, kaybolan belgelerin hızla belirlenebileceği ve durumu düzeltmek için adımlar atılabileceği anlamına geliyordu.

Tasarım İstisna İşleme Prosedürleri

İstisna işleme prosedürlerinin oldukça hafif ancak etkili bir şekilde nasıl oluşturulabileceğini görmek için, nedenlerini araştırmaya odaklanan bir bilimsel araştırma kuruluşunun CIO'suyken kariyerimde karşılaştığım başka bir gerçek dünya örneğine bakacağız. yaşlanma ve yaşa bağlı hastalıkların tetikleyicileri.

NIH tarafından finanse edilen tüm araştırma enstitüleri, her biri bir Baş Araştırmacı (PI) tarafından yürütülen ve çeşitli alt bilim adamları ve post-doc tarafından görevlendirilen birçok bireysel laboratuvar içerir. Bir noktada, PI'nin yeni bir çok odacıklı reaktif tepsisine ihtiyacı vardır, bu nedenle post-doc'lardan birinden gerekli talebi oluşturmasını isterler. Post-doc, talebi oluşturur ve bir PO'nun yükseltilmesini istemek için Finans'a e-posta gönderir ve PI'nin talebin gönderildiğinden haberdar olmasını sağlamak için PI'yi cc'ler. Bu arada, PI'nin, belirli bir tarihe kadar onay almadıkları takdirde istek durumunu kontrol etmelerini hatırlatmak için ayarlanmış bir otomatik takvim bildirimi vardır. Bu, post-doc gerekli isteği oluşturmayı veya göndermeyi unutması durumunda güvenli bir mekanizma sağlar.

Artık, post-doc aynı şekilde, belirli bir süre içinde PO'nun yükseltildiğine dair bir onay almazlarsa, Finans'ı kontrol etmek için otomatik bir takvim bildirimine sahiptir. Finans, PO'yu yükselttiğinde, belge sonrası, satıcıya gönderildiğine dair e-posta onayı alır ve belge sonrası, bu onayı PI'ye iletir.

Bu aşamada, ya PI ya da post-doc başka bir otomatik takvim bildirimi ayarlar ve belirli bir süre içinde satıcıdan hiçbir haber alınmazsa, birisinin PO'nun alındığından ve sevk edildiğinden emin olmak için satıcıyla kontrol etmesini sağlar. sipariş edilen ekipman.

Satıcının PO'nun alındığını kabul ettiğini ve öğeyi bir sevkiyat bildirimi ile birlikte gönderdiğini varsayarsak, bu, PI'ye veya post-doc'a yönlendirilir. Ardından, öğenin ortaya çıkmaması durumunda, ne olduğunu takip etmek ve öğenin doğru bir şekilde teslim edilmesini sağlamak için satıcıya ulaşmaları gerektiğini bildiklerinden emin olmak için planlanan teslim tarihinden sonraki üç gün için son bir takvim bildirimi ayarlarlar. Öğe planlandığı gibi ulaşırsa, belge sonrası Finans'ı bilgilendirir ve kuruluş varlık etiketleri kullanıyorsa, bu işlemler dizisi başlatılabilir.

Yolun her adımında, ana süreç akışı kesintiye uğrarsa düzeltici eylemin gerçekleşmesini sağlamak için gerekli açık bir onay ve bir alt süreç mevcuttur. Sarkan, onaylanmayan veya desteklenmeyen hiçbir şey kalmaz. Geçici eylemlere gerek yoktur çünkü herkes neyin gerekli olduğunu ve işler ters giderse ne yapacağını bilir.

SQL'den Kapalı Döngü İşlemleri Oluşturmayı Öğrenmek

İyi bir sürecin özü, SQL tabanlı ilişkisel veritabanlarının işlem tutarlılığını sağlamak için tasarlanma biçimine çok benzer. Herhangi bir eylemin tamamlanmış sayılması için onaylanması gerekir. Tüm iki yönlü iletişim, sürecin bir parçası olarak yerleşik açık bir onaya ve onayın alınmaması durumunda doğru eylemin yapılmasını sağlamak için geliştirilmiş alt süreçlere ihtiyaç duyar. Başarılı proje yöneticileri, bir işletmedeki bilgi akışını iyileştirmek ve kuruluşlara büyük miktarda zaman ve para tasarrufu sağlamak için kapalı döngü süreçleri oluşturmalıdır.