Kalite – Uygunsuzluk Yönetimi Süreci

Uygunsuzluk Yönetim faaliyeti
Bir Uygunsuzluk tespitine ve giderilmesine yönelik süreç örneği.

Süreç Hedefi
Sürecin hedefi, Şirketin iş süreçlerinde tespit edilen bir Uygunsuzluğu için düzeltici veya iyileştirici faaliyeti başlatmak.

İçerik
Uygunsuzluk yönetimi, tespit edilmiş uygunsuzluk veya potansiyel uygunsuzluk durumlarının saptanması ve olumsuzlukların giderilerek kalite yönetim sisteminin sürekli olarak iyileştirilmesi hedefleniyor.

Tetikleyici

Form – “Uygunsuzluk tespit Formu” karşılık gelir.

Eylemeler
Bu süreç içerisinde iki görevden birini tetikler: Düzeltici veya İyileştirici faaliyetlerinin oluşturulmasına sebep olur.

Tanımlar
Uygunluk: Bir şartın gerekliliğin yerine getirilmesi.
Uygunsuzluk: Bir şartın gerekliliğin yerine getirilememesi.
Saptanmış Uygunsuzluk: Uygunsuzluğun ortaya çıktığının tespit edilmiş olması.
UDF: Saptanmış bir uygunsuzluğun düzelterek ortadan kaldırılması için yapılan faaliyet.
DIF: Saptanmış bir uygunsuzluğun sebebinin tespit edilmesi ve uygun iyileştirmeler yaparak ortadan kaldırılması için yapılan faaliyet.

Şema-1: UDF Süreci (PDF olarak indir)

Şema-2: DIF Süreci (PDF olarak indir)

Şemadan da takip ettiğiniz gibi Sürecin ilerleyen bölümlerinde, Talebin önce ilgili Kalite Yöneticisi tarafından incelenir, Uygun bulunması durumunda Uygunsuzluk ile doğrudan ilişkisi bulunan Birim Yöneticisi görevlendirilir. Birim Yöneticisi sorunun “Düzeltici” faaliyet veya “İyileştirici” faaliyeti olup olmadığına karar verir.

Düzeltici faaliyet süreci ise;

  • Sorunu gidermek için aksiyon(lar) belirler ve sorunu gidermek için derhal gerekli çalışmalara başlar.
  • Sorunun giderilmesi ile Uygunsuzluğu tespit eden Personel tarafından kontrol edilir.
  • Yapılan çalışmaları değerlendirmek üzere kısa bir Anket doldurulur ve Uygunsuzluk bildirimi Kalite Yöneticisi tarafından kapatılır.

İyileştirici faaliyet süreci ise daha kapsamlı bir çalışma gerektirir, şöyle;

  • Öncellikle detaylı bir “kök-neden” araştırması gerçekleştirilir,
  • Kaynak planlaması (Gereksinimler, Bütçe ve Maliyet çalışması),
  • Risk değerlendirmesi,
  • Denetim kriterleri belirlenir,
  • Çalışma süreleri ve kullanılacak kaynakları içeren bir Aksiyon Planı hazırlanır.

Tüm bu Bilgiler öncelikle Kalite Yöneticisi ve gerek duyulması halinde Yönetimle paylaşılır. Uygun görülmesi durumunda planlanan çalışma başlatılır.
İyileştirme çalışmaları tamamlanınca Kalite Yöneticisi bilgilendirilir ve öncesinde belirlenmiş Denetim kriterleri dikkate alarak”İyileştirme faaliyeti” denetlenir. Uygun olması durumunda bir Teftiş Raporu hazırlanır, Dosya’ya eklenir ve DIF kapatılır.

Alanlar

[Tespit/Talep]
Referans takip Numarası,
Talep Bilgileri, (İsim, Görevi, Dept., talep Tarihi)
Uygunsuzluk tanımı ve soruna ait detaylı Açıklaması,
Uygunsuzluğun tespit edildiği yer (Lokasyon),
Durumu gösteren destekleyici ek Belge, Medya, link,
Uygunsuzluğun etki alanları (Süreç, maliyet, müşteri, ürün vs.),
Durumun önem derecesi ve çözümün gerekli olduğu Tarih.

[Değerlendirme]
UDF/DIF seçeneği ?
Kök-neden çalışma sonuçları
Aksiyon Planı
Maliyet ve Bütçe Kodu
Risk analiz sonuçları
Denetim kriterleri bilgileri
Yorum

Ana Makeleye geri dön

draw.io ile dilediğini tasarla

Draw.io ile hemen her şeyi ve istediğiniz şekilde tasarlayabilirsiniz, ister hazır örneklerden yola çıkın yada sıfırdan tasarlayın. Draw.io ile tasarımlarınızı GoogleDrive, Dropbox, OneDrive veya lokal Diskinizde saklama imkanı veriyor. Jira ve hemen her uygulama ile entegre edebilir veya uygulamanıza mevcut Sitenize gömebilirsiniz. Denemek için buraya tıklayınız.

Neleri tasarlayabilirim?

  • - BPMN diyagram
  • - Mockup tasarımı
  • - UML diyagramı
  • - Network diyagramı
  • - İş akış şemaları
  • - Ağaç diyagramı
  • - Zihin haritaları
  • - İlişki diyagramları
  • - Gantt Şeması
  • - Kabinet tasarımı
  • - Sıra diyagramı

Kullanıcı Hikayeleriyle Yelken açın

Deneyimleriniz çok değerli

“Süreç yönetimi” ve kullanımı giderek artan “Müşteri odaklılık”, şirketlere önemli bir yer almaktadır.

Pazarlama departmanları müşteri bakış açısını yakalamak ve temas noktalarını tanımlamak için çabalıyor, öbür yandan Süreç yöneticileri süreç sahipleri ile birlikte iç süreçlerine odaklanıyor. Halbuki her ikisini bir araya getirilmesinde çok büyük yarar olduğunu düşünebiliriz. Lakin, Kullanıcı davranışlarını iyi bilmeniz ve bu bilgileri şirketin tüm kademeleriyle paylaşılmasında yarar var.  Dahası, aynı Bilgilerin iş süreçlerinize dahil etmeniz durumunda gerçek anlamda “Müşteri odaklı iş süreçlerine” sahipsiniz demektir!

Günlük hayatımızda klasik bir örneğe bakarsak neyin önemli olduğunu hızlı bir şekilde açıklıyor oluruz;

Bir teknisyen müşteriye bir tamir işi için gider, işini yapar ve onarım tamamlandığı taktirde şirket için bu işin başarılı bir şekilde yapıldı demektir. Ancak Müşterinin bu konuda ki görüşü oldukça farklı olabilir; Müşteri Teknisyenin geciktiği, dostça olmadığı ve çalışma ortamını temiz bırakmadığından dolayı sinirlenmiş ve mutsuz olabilir! Müşteri, sosyal medyada olayla ilgili şikayette bulunurken, süreç şirket için başarıyla tamamlandı, öyle mi? Kesinlikle -EVET-.

Bu örnek Müşteri memnuniyeti ve Şirketin süreçleri ne kadar ayrı olabileceğinin bir kanıtıdır.

Bu gibi olumsuz durumlarda Müşteri hizmetleri Anketleri de yanıltıcı olabileceğini biliyoruz. Size darılmış bir Müşteri artık “Müşteri” sıfatından çıkıyor demektir. Eğer ortada bağlayıcı bir Sözleme yoksa bir sonraki deneyimi başka bir Şirketle gerçekleştirme olasılığı yüksektir.

Tavsiyem ise, işlerinizi etkileyebilecek olumlu veya olumsuz tüm Müşteri deneyimlerinizi uzun bir süre dikkatle gözlemlemeniz ve elde ettiğiniz bu tecrübeleri ilgili iş süreçleriniz de dikkate almanızdır. Bu iş birliği sayesinde Şirketiniz;

  • – Vakalara göre yeni Çözümler üretebilir,
  • – Deneyimler sayesinde Müşterilerinizi heyecanlandırabilir,
  • – Şirkete gerekli çeviklik ve rekabet gücü sağlayabilirsiniz.
  • – Yenilikçi düşünce şirketinizde yaygınlaştırabilir,
  • – Şirketiniz uzun vadede önemli başarılar elde edebilirsiniz.  

Evet belki hatırlarsanız, “OPET” müşteri memnuniyetini tüm İstasyonlarında Tuvaletlerin temizliğini Reklam ederek başardı. Yolculuklarımızda hepimizin ortak sorunları çözerek bir fırsata dönüştürdü. “Müşteri sadakati” yönünden de Sektörün birçok Dünya Markasını sollayıp geride bıraktı.

İyi bir gözlem, harika bir kullanıcı deneyimi ve doğru zamanda.

 Neden kullanıcı hikayeleri?

Kullanıcı hikayeleri, ürününüzü veya hizmetinizi net bir şekilde tanımlamanın mükemmel bir yolunu sunar. İyi tanımlanmış, öncelikleri belirlenmiş bir “kullanıcı öykü seti” teknik ve uygulama ayrıntılarından uzak, “sade bir dil” kullanarak ürün ve hizmetinizin işlevselliğini açıklamanıza yardımcı olabilir.

“Kullanıcı hikayesi” yaklaşım modeli hem ürün geliştirme ekibinin içerisinde hem de dış paydaşlarla anlamlı ürün tartışmalarına imkan verir.

Düzgün bir şekilde yazılmış kullanıcı hikayeleri, iletişim ve iş birliği açısından Ekibe sağlam bir temel oluşturur- kullanıcı için en önemli olan ihtiyaçlarına odaklanır. Kullanıcı gereksinimlerini ve ürün özellikleri yakalamak ve gereksinimleri belgelemek için diğer araçlarla karşılaştırıldığında, en azından aşağıdaki avantajlara sahiptir:

  1. Kullanıcı hikayeleri, neyin, kimin, niçin ve ne zaman yapılacağına dair takımlar arası netlik sağlamaya yardımcı olur. Tanımlanması, anlaşılması ve güncellenmesi kolay olduğundan, ürünün işlevselliğini hem teknik hem de teknik olmayan ekipler tarafından ortak bir standart yolu olabiliyor. Ürün kapsamı belirlemek, üzerinde tartışmak veya teknik dalışlar için giriş noktaları olarak son derece kullanışlıdır. Bunlar çevik mühendisliğin kilit unsurlarıdır.
  2. Kullanıcı hikayeleri teknik olmayan üyelerin katılımını teşvik eder. Modern yazılım projeleri çok çeşitli teknolojileri, kısaltmaları ve uygulama seçeneklerini içeren tipik olarak fazlasıyla karmaşıktır. Çoğu durumda, terminoloji veya teknik dil, tek bir ekip içinde bile yaygın olarak anlaşılmamaktadır, bu nedenle yanlış anlamalara sebep olabilir ve projeye risk altına girebilir. Kullanıcı öyküleri bu teknik boyutu kaldırır, böylece ekipler yalnızca bir son kullanıcı bakışı açısından düşünerek katkıda bulunabilir. Ekip teknik olmayan bir dil kullanarak kullanıcı öykülerinin tanımlanmasında ve önceliklendirilmesinde etkin bir rol oynar. Buda iş birliğinin ve takım dinamikleri üzerinde önemli bir avantaj ve etki yaratabilir.
  3. Sağlam, akıllıca önceliklendirilmiş öyküler kümesi ürünü tanımlanmasında yardımcı olur. Ürün geliştirme ekibi artık büyük düşünebilir, kullanıcı öykülerinin setini tanımlayabilir ve daha sonra öncelikleri belirleyebilir (kullanıcı açısından beklenen değeri, karmaşıklığı, bağımlılıkları ve diğer işe bağlı önceliklerini yansıtır). Zor kararlar vermek zorunda değilsiniz, bazı çalışmaları “kapsam dışı” olarak değerlendirmek zorunda kalabilirsiniz. “Kapsam dışı” yerine, ürününüzün temel işlevlerini yansıtan kullanıcı hikayelerinin sırasını yükseltirken, “çılgın” fikirlere daha düşük öncelik atayabilirsiniz. Fakat unutmayın, “çılgın fikirler” yenilik açısından son derece değerli ve ilk bakışta “çılgın” olarak görülen bir yaklaşım önerisine biraz daha emek vererek, inanılmaz sonuçlar alabilirsiniz!

Harika kullanıcı hikayeleri yazmak 

Evet, öykü yazmak kolaydır. Ancak etkin hikayeler yazmak biraz zor olabilir. İşte dikkat etmeniz gereken bazı kurallar:

Kullanıcı hikayeleri ≠ görev değildir

Kullanıcı hikayeleri bir görevi temsil etmez ve kesinlikle görev değildir. Aslında, tek bir hikayenin başarılı bir şekilde yerine getirilmesi için yüzlerce göreve ihtiyacı olabilir. Görevler uygulama ile ilgilidir; kullanıcı hikayeleri ise tanımla ile ilgilidir.

Hikayelerinizi derlerken, ürün özellikleriniz hakkında netlik sağlamaya odaklanın – ne, ne değildir?

Yüzeyde kalın

Yüzeyde kalın, detayda boğulmayın ama aynı zamanda hedefi kaçırmayın. Hikayeler basit ve sağlam olmalıdır. Bu, ekip üyelerinin ve paydaşların kullanıcı ihtiyaçlarını derinlemesine anlamalarına yardımcı olacak. Gereksiz terminoloji ve kısaltmalar netleştirmek için zaman harcamayın , sadece basit ve doğru bir dil kullanın.

Kullanıcılarınızı anlayın (empati kurun)

Ürününüzün gerçek kullanıcılarını keşfetmeniz ve incelemeniz gerekir – profilleri, bakış açılarını, beklentilerini ve ilgili ‘sorun noktalarını’ yakalamaya çalışın. Kullanıcı araştırması ve diğer teknikler, kullanıcıları ve ihtiyaçlarını daha iyi anlamanıza yardımcı olacak bilgiler sağlayabilir. Teknikler ne olursa olsun, kullanıcı öykülerini derlemeye başlamadan önce kilit kullanıcı grubunun kişilikleri hakkında bilgiye ihtiyacınız olacak – empati kurun.

Bir kullanıcı olarak düşünün

Bir kullanıcı öyküsünün açısından (belirli bir kullanıcı / kişi / rol sınıfı olarak) bakınız. Bu bakış açısını, belirli bir kullanıcının öyküde özetlenen işlevselliği nasıl algıladığını tanımlar. Bu kritik öneme sahiptir – Ürün sahibi ve tüm çalışma ekibi, kullanıcının bakış açısıyla düşünmeli ve temel ihtiyaçları ve beklenen değeri anlamalıdır.

Büyük düşün

Bir ürüne ait kullanıcı hikayelerini oluştururken ve tanımlarken, düşüncenizde bütçe, zaman, fizibilite veya maliyet gibi kavramlar için yeri yoktur. İyi bir uygulama, büyük düşünmek ve “ÇILGIN” kullanıcı hikayelerinin iş akışına girmesine izin verilmeli. Mevcut bir ürünün sürdürülmesi açısından giderleri azdır; fakat ondan türeterek elde edilen değer, ürün netliği, vizyon ve fırsatlar açısından çok büyük.

Hikayelerin gücü 

Kullanıcı hikayeleri aslında basittir demiştik ve kullanıcının bakış açısından işlevsellik ifade ederken, Ürün ve hizmet geliştirmek için son derece güçlü bir araçtır. Belirli bir kullanıcı veya kullanıcı grubunun neye ihtiyaç duyduğunu ve kazanılacak değeri yansıtır demiştik.

Yöntem basit ve kullanımı son derece kolaydır. Aşağıda gibi çeşitli varyasyonlar vardır:

Bir <rol veya kişi> olarak şunu yapar <hedef/ihtiyaç> , böylece <neden veya değeri> elde ederim”

Veya, başka bir durumda:

“<Belirli bir kullanıcı grubu> olarak, <bir şey yapabilir> böylece <bir çeşit değer/avantaj elde edebilirler> “

olacak şekilde…

Örneğin:

 “Adnan bir Üniversite öğrencisidir”  <rol> ve özel sağlık nedenlerinden dolayı sadece  “Vejetaryen gıda alması gerekiyor” <hedef/ihtiyaç>. Eğer Kampüs içi veya yakınlarında bir Yemek yeri bulabilirse, “Ders aralarında ihtiyacı olan Gıdayı alabilir” <neden>.

Bu örnekle ilgili çözümlerden biri, Kampüsün farklı yerlerine birkaç tane soğuk yiyecek ve içecek Otomatı yerleştirmek olabilir. Böylece Öğrencilerin ihtiyaç duydukları Ürünleri uzaklaşmadan Kampüs içerisinde farklı Noktalardan temin edebilirler. Temel gereksinimleri  söyle sıralayabiliriz;

  • – Yiyeceklerin taze,
  • – İçeceklerin soğuk,
  • – Ürünler ambalajlı,
  • – Ürünler çeşitli olmalıdır,
  • – Hayvansal gıdanın yanı sıra diyet ürünleri ve Vejetaryenlerde hitap etmelidir.
  • – Ürün fiyatları Öğrenci profiline göre uygun olmalı,
  • – Madeni ve kağıt para dışında Kredi Kartı geçerli olması büyük bir kolaylık sağlar.

İlk kurgu da aklımıza gelen beklentiler bu şekilde olabilir ama gerçekten çok daha fazlası vardır…

“Peki Dolapta gerçekten ne olmalı, kim veya kimler buna karar veriyor? “

Bu soruya doğru cevap vermeden önce Kullanıcı profilleri çıkartmalıyız. Bu tür tespitleri için normalde Şirketin İş geliştirme sorumlusu veya Bölge Sorumlusu tarafından kurgulaması size doğru gelebilir – fakat tek başınıza bir Proje (Ürün) geliştirmeniz ve çözüm üretmeniz doğru bir yöntem değildir.

Standart bir uygulama değilse, farklı kademelerden farklı görüşlere sahip, grup içerisinde fikir üretip bu fikirleri olgunlaştırmamız gerekiyor. Bazen Projeleriniz benzer olabilir ama temelinde tekildir. Katılımcılar arasında Satış & Pazarlama, Müşteri hizmetleri, Bölge Sorumluları ve Teknik ekip gibi bu çalışmanın içerisinde olmalılar.

Unutmayın doğru ekibi kurmak için farklı görüşlere sahip insanlara ihtiyacınız var!  

Ama önce sahaya inerek birkaç Öğrenciyle görüşerek beklentilerini almanız vizyonunuzu genişletecektir.

Görüşleri ister olumlu ister olumsuz olsun, size çok şeyler katacaktır. Örneğin birçok Kullanıcı bu tür Otomatlarla ilgili bazı ortak sorunları dile getirmişlerdir:

İşin zorlukları Derece
Paramı alıyor ama Ürün vermiyor **
Madeni para sıkışıyor ve bana iade edilmiyor. ***
Kağıt parayı okumuyor ve hemen iade ediyor. ***
Yanlış Ürün veriyor. *
Seçmek istediğim düğmeler çalışmıyor. *
Ürün otomat kısmında sıkışıyor/ Teknik Servis Nr. cevap vermiyor. ***
Sevdiğim Ürün çabuk tükeniyor **
Sevdiğim Ürün hiç bir zaman bulunmuyorum. ***
Ürüne ait son kullanma tarihi ve/ya Ürünün içerdiği maddeleri görmeden almak istemiyorum *

* (nadir), ** (orta), *** (sıkça görülen)

Tabloda gördüğünüz gibi, üç başlık  – Ödeme , Ürün çeşitliliği ve teknik sorunlar öne çıkıyor;

  1. Ödeme ile ilgili şöyle bir çözüm önerisi getirebiliriz. -Öğrencilere Kampüs kartları veya mevcut Ulaşım Kartlarını kullanarak alışveriş imkanı sağlanabilir. Bu çözüm için gerekli teknik entegrasyonu değerlendirilebilir.
  2. Ürün çeşitliği sağlayabilmek için, istek Formu doldurup,  çeşitliliği arz-talep yöntemiyle değerlendirilebilir. Talep formuna ulaşmanın en hızlı yolu ise, Cihazın (Kare) bar-kodu kullanarak web üzerinden ankete yönlendirmesi sağlanabilir.
  3. Teknik sorunlara karşın Teknik Servise ulaşmak için bir “Acil” Numara aranabilir. – Önemli olan bu Telefonu arandığında cevap verilmesi sağlamak 🙂 -Diğer yandan, Firma IOT gibi Teknolojilere yatırım yapabilir ve böylece anında arıza, dolabın ısı değerlerini ve doluluk oranı gibi birçok farklı verileri online takip edebilir ve zamanında müdahale kabiliyeti kazanır.

Hatırlayalım

Kullanıcı Hikayelerinizi zenginleştirirken daima Kullanıcı gözüyle bakarak Ürününüzü geliştirin. Sadece yeniliklere odaklanın ve başkasının fikirlerini küçümsemeden veya “Çılgın” olarak nitelendirmeden kolektif bir şekilde fikir üretmeye bakın.

Umarım bu Makale faydalı olmuştur.

Önerilen Tasarım araçları: Trisotech Enterprise Suite, Signavio Process Manager

CMMN nedir?

Kurum ve Kuruluşlar, verimliliği artırmak ve hataları azaltmak için çalışma biçimlerinde daima iyileştirmeler yapmaktalar. Bu çalışmalar arasında, öngörülebilir ve yapılandırılmış iş akışlarını takibe alarak analiz sonrası süreçlerinde sürekli iyileştirilmesini sağlanıyor.  Peki bu çalışmaları yürütürken karşınıza, sabit bir sürecin değişkenlerine tam cevap veremediğimizde ne yapmalı?

Bu gibi durumlarda sorunu tam olarak anlayabilmemiz için farklı bir model yaklaşımı gerekiyor.- Tam burada CMMN işinize yarayabilir!

CMMN = “Case Management Model and Notation” yani “Vaka Yönetimi Modeli”

CMMN, değişen durumlara ve öngörülemeyen bir sırada gerçekleştirilebilecek çeşitli faaliyetleri “VAKA” çerçevesinde değerlendirilmesi için kullanılan grafiksel bir Metodudur. CMMN “Olay merkezli” bir yaklaşım ile BPMN’nin statik sınırlarını genişletebiliyor. İkisini bir arada kullanarak çok daha geniş bir bakış açısı sağlayabilir.

Örneğin, bir Otelin misafiri, giriş ve çıkış işlemleri her zaman aynı süreçten geçebilir, oysa Odayı temizlemek için düzenli görevler bile Olaya göre günden güne değişebilir.

CMMN ilk kez 2014 Yılında OMG.org tarafından geliştirilip yayınlanmış. Güncel olan 1.1 (2016) sürümünden anlayacağınız gibi nispeten yeni bir standarttır ve İş süreçlerinde daha fazla esneklik sağlamak için geliştirilmiştir. Bu standarttı kullanarak süreç sahipleri kolaylıkla yeni bir vaka tasarımı hazırlayabilir veya mevcut bir vakanın analizi yapılabilir. Model sade ve BPMN gibi kuralları değil, Görevlere ve ona ait bağımlılıklarına odaklanıyor. Bir Vakayı tetiklemek için bir olaya, göreve veya aşmaya (hedef taşına) ihtiyaç duyulur. Dediğimiz gibi CMMN’nin en belirgin özelliği ise bir göreve ait tüm bağımlılıkları gösterebilmenizdir.  Örnekte görüldüğü gibi önce” kirli havlu ve Çarşafları çıkar” (Bağımlılık) sonra yenisi ile değiştir (Ana görev). BPMN modelinde ise bunu tek bir Görev olarak belirtmem yeterlidir, yani “Havlu ve Çarşafları değiştir”.

CMMN, bir problemin akışını modellemeye çalışmıyor; İstedikleri sonuçları belirlerler, yani BPMN gibi iş akışı kontrol ederek  nasıl olmasını gerektiğini değil, arzuladığımız hedef ne olması gerektiğini belirtir.

CMMN Şema-1: Hotel Oda Servisi Vakası

 BPMN Şema-2: Hotel Oda Servisi Süreci

Özetlersek, CMMN’nin kullanım amacı;

  • Süreç içerisinde doğrudan bir iş akışa dahil olamayan değişken görevler olması durumunda.
  • İş sürecinize ait Görevleri ve hedef -taşları şeffaf bir şekilde modellemek.
  • Süreç akışına değil, daha çok olayları odaklanır.
  • Tasarım ortamında Görevlere arasında öncelikleri kolayca belirtmek.
  • Varsa, Göreve ait bağımlılıklarınızı (alt-görev veya destek görev) ortaya çıkarmaktır.

Kendi Vakalarınızı tasarlamak isterseniz,  Camunda BPM ücretsiz kullanabileceğiniz bir Modelleme aracı sunuyor ve buradan indirebilirsiniz. Bu Araç BPMN, DMN ve CMMN gibi Modelleme desteği bulunuyor. CMMN Notasyonu daha yakından tanımak için;

  1. Knut Hinkelmann’nın yayınladığı (PDF) kaynağını buradan ulaşınız.
  2. Veya doğrudan OMG’nin referanslarına ulaşmanızı tavsiye ederim.

Kaynak referanslar: Signavio CMMN, Visual Paradigm, OMG

Önerilen Tasarım araçları: Trisotech Enterprise Suite, Signavio Process Manager

👏

İş bağlantıları takip süreci

İş Bağlantıları Takibinin Sağlanması

Satış fırsatı (sales-opprtunity) sağlayacak bir iş bağlantısının kurulmasına yönelik süreç örneği

Süreç Hedefi

Satış fırsatı oluşturacak bir iş bağlantısı kurun.

İçerik

Satış müdürleri, genellikle hem nitelikli hem de spontane temas ettikleri iş ortaklarıyla birçok toplantı düzenlerler. Bu nedenle nitelikli kişiler ile kurulan iş ortaklıklarını arttırmak adına bir sınıflandırmanın yapılması şarttır. Geleneksel olarak, bu sınıflandırma kartvizitlerin üzerine alınan notlarla yapılır. Örneğin, bir bağlantının şimdi, sonra ya da hiçbir zaman kurulmayacağı not alınabilir. Sınıflandırmaya göre, doğrudan bir toplantı yapmak için anlaşılabilir ya da nazik bir e-posta gönderilebilir. Signavio İş Akışı Hızlandırıcısı, büyük bir satış-hattı görevi (Sales-Pipeline Tool) oluşturmak yerine, size süreci yapılandırıp merkezi olarak yönetmenize olanak tanır.

Tetikleyici

Form – Kişinin iletişim bilgileri özelleştirilir ya da direkt bir kartvizit taraması da yapılabilir.

Eylemler

Süreç, iş toplantısının sonucunu belgeleyerek bu sonuç ışığında kurulan bağlantıları bir sınıflandırma içerisine sokar.

Roller

Satış Uzmanı– Bir iş geliştirme ve satış ekibi çalışanıdır. Bu, süreç çalışanlar arası bir işbirliği gerektirmediği için bulunan tek roldür.

Alanlar

Sürecin temel verileri, satış müdürünün sınıflandırma ve bağlantı takibi için ihtiyaç duyduğu bilgilere dayanmaktadır.

  • Bağlantının adı (yazı, gerekli alan) – Potansiyel müşterinin adıdır.
  • Telefon numarası (metin) – Satış müdürü ayrı bir defter tutmuyorsa bağlantının numarasını içerir.
  • İş ünvanı, firma (yazı) – Satış yöneticisinin, bağlantıyı sınıflandırma esnasında dikkate alabileceği ünvanı.

Uzantılar

Satış sürecini, bir sonraki adımı da kapsayacak şekilde geliştirebilirsiniz. Örneğin, ürün tanıtımının yapılması. Toplantı bulguları, bir sekreter ile koordinasyonu gerektirebilir. Böylece ürün tanıtımı bir ürün uzmanıyla işbirliğini gerektirir.

Kaynak: Signavio 

Ana Makeleye geri dön