ERP arayüz teklifi: önce veri sorumluluğunu netleştir

Sistemleri bağlama isteği içeren bir ERP talebi çok farklı hizmetlere dönüşebilir. Bir çevrim içi mağazanın sipariş aktarması istenebilir. Değişen ürün bilgilerinin geri dönmesi de beklenebilir. Muhatabın aynı bağlantıyla stokları ve teslimat bildirimlerini de kastediyor olabilir. Bu nedenle teklifinde her aktarımın açıklamasına ihtiyacın var. Böylece müşteri hangi iş akışını sipariş ettiğini görür, ekibin de sınırları belirlenmiş bir kapsam hazırlar. Yalnızca program adlarını sıralamak bu kararı henüz çözmez.

Bu rehber ERP sağlayıcılarına ve uygulama ortaklarına yöneliktir. Belirli bir bağlantı için teklif verilip verilemeyeceğine veya önce müşteri ve diğer sistem ortaklarıyla sınırlı bir inceleme gerekip gerekmediğine karar verirsin. Sorular kendi satış çalışmana aittir; taleple birlikte sağlanan ek veri alanları değildir. Bütün örnekler açıkça kurgusaldır ve kişisel müşteri verisi içermez. Teknik yöntemleri ve performans taahhütlerini ancak gerçekten kullanılan ürünleri, sürümleri ve onaylı ortamı inceledikten sonra belirle.

Tamamlanan bir aktarımla başla

Müşteriden bir aktarımı başından sonuna anlatmasını iste. Gelen mağaza siparişi yararlı bir başlangıçtır: Nerede oluşur, ERP hangi bilgilere ihtiyaç duyar ve satış ekibi işleme devam edilebileceğini nasıl anlar? Beklenen son durumu çalışanların diliyle kaydet. “Sipariş iş açısından incelemeye hazır” ifadesi, “mağaza ERP’ye bağlı” ifadesinden daha açıktır. Sonraki otomatik işlemlerin istenen kapsama dahil olup olmadığını da öğrenirsin.

Ardından ters yönü ele al. Mağazanın doğru durumu göstermesi için hangi bilgi geri dönmeli? Alınmış sipariş, onaylanmış teslim tarihi ve gönderilmiş sevkiyat farklı olaylardır. Bu farkları açıkça konuşmak, muhatabının ihtiyaç duyduğu geri bildirimi seçmesini sağlar. Her ek yön için ayrı bir kayıt oluştur. Böylece tek bir arayüz sanılan bağlantının birden çok iş görevine dönüşüp dönüşmediği ve hangilerinin ilk teklife gerektiği görünür olur.

Hangi bilginin nerede esas alındığını belirle

İlgili veri türleri için esas alınan kaynağı sor. Ürün numaralarını kim açıyor, açıklamaları kim değiştiriyor ve belirli bir siparişin teslimat adresi nerede düzeltiliyor? Yanıt veri türüne göre değişebilir. Müşteri yalnızca ürün bakımını anlattıysa genel olarak “ERP esas alınır” yazma. Hangi bilginin hangi sistemden alınacağını ve değişiklikleri iş açısından kimin değerlendireceğini açıkça belirten teklif daha anlaşılır olur.

Çelişen değişiklikleri de incele. Kurgusal örnekte mağazadaki sipariş adresi değiştirilirken bir çalışan ERP’ye farklı bir adres girer. Bu sipariş için hangi kaydın geçerli olacağını ve çelişkiyi kimin çözeceğini sor. Otomatik bir kuralı ancak iş kararı bilindiğinde değerlendirebilirsin. Gerçek bir adres dosyası gerekmez. Çelişkiyi görünür kılmak ve sorumlu rolü belirlemek için başlangıçta uydurulmuş bir açıklama yeterlidir.

Veri aktarımı ile iş sonucunu ayır

Bir mesajın aktarılması bütün operasyonel soruları yanıtlamaz. Müşterinin hangi onaya ihtiyaç duyduğunu netleştir: Mesaj ulaştı mı, içerik kabul edildi mi, yoksa oluşan sipariş iş açısından onaylandı mı? Bu durumların iş akışındaki sonuçları farklı olabilir. Sonraki insan eylemini sor. Satış bir kaydı kontrol etmek isterken depo yalnızca ayrı bir onaydan sonra harekete geçecek olabilir. Bu ayrımı açıklamaya dahil et.

Her aktarım için basit bir test örneği ve beklenen gözlemi yaz. Kurgusal mağaza siparişi bilinen bir ürün ve açıkça uydurulmuş bir teslimat adresi içerir. ERP siparişi inceleme için göstermelidir; sonraki teslimat sözü bu örneğin dışındadır. Böylece müşteri kapsamlı teslimat otomasyonu varsaymadan kararlaştırılmış durumu değerlendirebilir. Bilinmeyen ürün içeren ikinci bir örneği konuş. Doğrulanmış akışa uygunsa görünür bir açıklama talebi beklenen sonuç olabilir.

Güncelliği müşterinin işi üzerinden belirle

Aktarım teknolojisi önermeden önce değişikliğe ne zaman ihtiyaç duyulduğunu sor. Satışın bir sonraki sözünden önce yeni durumu bilmesi mi gerekir, yoksa kararlaştırılmış daha sonraki işlem yeterli midir? Gecikmede hangi iş adımı bekler? Bu sorular gerçek ihtiyacı ortaya koyar. “Otomatik” sözcüğü belirli bir hızı veya kesintisiz kullanılabilirliği ifade etmez. Her ikisi ayrı inceleme ve çözüme uygun bir hizmet açıklaması gerektirir.

İstenen güncelliğin mevcut çalışma şekline uyduğunu kontrol et. Çalışan veriyi yalnızca elle onayladıktan sonra yayımlıyorsa daha sık teknik sorgulama tek başına yeterli olmaz. Bu onayın bilinçli olarak korunup korunmayacağını sor. Korunacaksa aktarım sırasına dahildir. Müşteri adımı değiştirmek istiyorsa bunu ayrı bir iş kararı olarak kaydet. Ekibin netleşmemiş bir iş sürecini fark etmeden üstlenmeden teknik kısmı inceleyebilir.

Soruları ve yeniden işlemeyi hesaba kat

Bir aktarım iş açısından işlenemediğinde çalışanların ne görmesi gerektiğini konuş. Bildirimi kim alır, hangi bilgiye ihtiyaç duyar ve konunun çözüldüğünü nasıl anlar? İş örneğine bağlı kal. Eksik ürün, ürün kayıtlarından sorumlu kişinin kararını gerektirebilir; eksik sipariş başka bir role ait olabilir. Teknik mesaj, birinin uygun sonraki adımı çıkarmasını sağladığında yararlıdır.

Aynı işlemin yeniden aktarılmasını da sor. Mevcut sipariş tanınmalı, güncellenmeli veya incelemeye mi sunulmalı? Gerçekte hangi tanımlayıcı kullanılabilir? Uzman ekip yöntemi değerlendirmeden satışın mükerrer siparişleri önleme sözü vermemeli. Teklifte istenen durumu ve henüz doğrulanmamış ön koşulu ayrı belirtebilirsin. Böylece müşteri neyin netleştiğini ve uygulama öncesinde hangi incelemenin gerektiğini görür.

İlgili sistem ortaklarını sürece kat

Bağlantı iki taraftan da bilgi gerektirir. Müşteriden bağlı sistemin sorumlu muhatabını ve ilgili ürün belgelerini iste. Somut sürüm, erişim seçenekleri ve uygun test olanağı hakkında kimin bilgi verebileceğini netleştir. İlk görüşme için genel satış notuna erişim bilgileri yazman gerekmez. Öncelikle sorumlu kişilerin öngörülen aktarımları iş ve teknik yönleriyle birlikte inceleyebilmesi önemlidir.

Katılımcıların hizmetlerini açıkça paylaştır. Ekibin ERP tarafını, mağaza hizmet sağlayıcısı başka bir görevi üstlenebilir. Ortak testi kimin koordine ettiğini ve açık soruları kimin takip ettiğini sor. Ortağın adını teklife yazmak bu sorumluluğu açıklamaz. Ürün eşleştirmesine karar vermek gibi gerekli müşteri katkısını da belirt. Böylece müşteri farklı sorumluluk sınırları içeren teklifleri karşılaştırabilir ve eksik işleri siparişten önce görebilir.

Teklif ile ön inceleme arasında karar ver

Güvenilir teklif için hangi bilgilerin bekleyebileceğini, hangilerinin kapsamı açık bıraktığını belirle. Henüz belli olmayan muhatap ile netleşmemiş aktarım yönü farklı durumlardır. Temel ön koşullar bilinmiyorsa, şirketin gerçekten sunuyorsa sınırları belirli bir analiz öner. Mutabık kalınmış aktarımlar ve açık teknik ön koşullar gibi sonucunu açıkla. Sabit fiyat, kesin süre veya otomatik olarak takip edecek uygulama siparişi uydurma.

Netleşen noktaları kısa bir hizmet açıklamasında topla: başlangıç olayı, veri türü, esas kaynak, yön, beklenen son durum, soruların ele alınması ve sorumlular. Açıkça hariç tutulan aktarımları da ekle. Müşteri yalnızca siparişlerin mi, stok ve teslimat bildirimlerinin de mi ele alındığını görebilmeli. Açık ön koşullar için gereken somut onayı belirt. “İlgili bütün sistemlerin bağlanması” bu ortak açıklamanın yerini tutmaz; herkes farklı anlayabilir.

Kapsamı başka bir örnekle kontrol et

Mağazadan sipariş almak isteyen açıkça kurgusal bir satıcı düşün. İlk kapsamda gelen siparişler incelemeye hazır hale getirilir. Sonra müşteri kısmi teslimatların otomatik geri bildirimini ister. Ekibin bunu kendi son durumu ve sorumlusu olan ek bir aktarım olarak ele alır. İlk karar anlaşılır kalır. Kullanılmış bir tanımı giderek daha fazla hizmetle doldurmak yerine genişleme bilinçli biçimde konuşulabilir.

Aynı kapsamı görüşmeye katılmamış bir çalışma arkadaşının gözünden incele. Siparişin nerede oluştuğunu, çelişen değişiklikleri kimin karara bağladığını ve müşterinin kararlaştırılmış işlemeyi nasıl tanıdığını anlatabilir mi? Varsayım gerekiyorsa yalnızca eksik ifadeyi ekle. Daha uzun program listesi burada fazla yardımcı olmaz. Sonucun kullanılabilir bir teklif sınırıdır: İş açısından yeterince açıklanmıştır veya müşterinin bilinçli biçimde sipariş edebileceği somut bir sonraki açıklamayla eşleştirilmiştir.

Aynı işlemin anlamlarını ve değişikliklerini kontrol et

Gerekli bilgilerin anlamını da karşılaştır. Miktar adet, koli veya kararlaştırılan başka bir birimi ifade edebilir. Ürün numarasının mağazada ve ERP’de farklı eşleştirmesi olabilir. Uydurulmuş örneklerle bu akışta hangi birim ve eşleştirmenin geçerli olduğunu sor. Teknik olarak dolu bir değer ancak iki taraf da aynı şeyi anlıyor ve eşleştirmeyi izleyebiliyorsa iş açısından değerlendirilebilir.

Sonra aktarılmış siparişteki değişikliği ekle. Örneğin müşteri ERP kaydı oluşturulduktan sonra miktarı azaltır. Hangi işlem aşamasına kadar değişikliğin öngörüldüğünü ve kimin inceleyeceğini sor. İncelemeden önceki değişiklik, uygulama başladıktan sonrakinden farklı işlem gerektirebilir. Henüz teknik çözüm çıkarma. Önce her iki durum için istenen iş tepkisini ayrı kaydet.

İptali de ele al. Sipariş geri çekildiğinde iki sistemde ne görünür kalmalı? Kararı kim verebilir ve ardından hangi çalışan bilgilendirilmeli? İstenen akışı müşteriyle incele; buradan genel bir hukuk kuralı çıkarma. Teklifin açısından bu örneğin kararlaştırılmış kapsama dahil olup olmadığı önemlidir. Daha sonra ele alınacaksa ortak açıklamada sınırı açıkça belirt.

Muhatabından örnekleri kendi sözleriyle anlatmasını iste. Giriş, değişiklik ve iptali ayırması, ekibinin her örneğin teknik yapılabilirliğini hedefli biçimde incelemesini sağlar. Anlam açık değilse sonraki soru tam o eşleştirmedir. Böylece daha önce yalnızca genel bağlantı isteğini bilen diğer sistem ortağı için de anlaşılır bir çalışma temeli oluşur.

Kaynak bağlamı

Microsoft, Dynamics 365 entegrasyonlarında sistemler arası süreç gereksinimlerini iş hedefleriyle ilişkilendirmeyi önerir. Üreticinin entegrasyon özeti burada yalnızca bu bağlam içindir; ürününün arayüz yeteneğini kanıtlamaz.

Yeni ERP görüşmelerine hazırlan

webRichtung ERP talepleriyle Almanya’da ERP teklifi arayan şirketlere ulaşabilirsin. Talep süreç alanını, mevcut sistem durumunu, planlama aşamasını, konumu ve iletişim bilgilerini içerir. Somut ürün ve arayüzleri sen netleştirirsin. Şirketini kaydet ve webRichtung Customer içinde talep siparişini hazırla; bağlayıcı siparişten önce güncel fiyatı görürsün.