Bağcılar’da özel yazılım: Excel ve mesajlarla yürüyen işler ne zaman tıkanır?

Sipariş mesajda duruyor, son fiyat Excel dosyasında, müşterinin istediği değişiklik ise bir çalışanın telefonunda. İşletme sahibi günün sonunda “Bu iş hangi aşamada?” diye sorduğunda cevap almak için birkaç kişiyi aramak gerekiyor. Herkes meşgul olabilir, fakat hangi işin neden beklediği görülemeyebilir. Aynı bilgiyi tekrar yazmak, eski dosyadan işlem yapmak ve bir işi takip etmeyi unutmak günlük düzenin parçası hâline geldiyse sorun yalnızca yoğunluk olmayabilir.

Bağcılar’da özel yazılım projesi yaptırmayı düşünen bir işletme için ilk soru hangi programın alınacağı değildir. Önce mevcut işin nerede tıkandığını anlamak gerekir. Bazı sorunlar ortak bir dosya ve açık görev paylaşımıyla çözülebilir. Bazıları hazır bir araçla karşılanabilir. Standart çözümlerin dışında kalan kurallar ve ekipler arasında sürekli kopan bilgi varsa, işinize göre bir uygulama geliştirmek daha anlamlı hâle gelebilir. Bu yazı, bu seçenekler arasında günlük işiniz üzerinden karar vermenize yardımcı olmak için hazırlanmıştır.

Hangi tekrarlar artık normal iş yükü olmaktan çıkar?

Aynı müşteri bilgisinin teklif, sipariş ve teslim listesine ayrı ayrı yazılması ilk bakışta küçük bir iş gibi görünür. Ancak müşteri adresi veya sipariş miktarı değiştiğinde bütün kopyaların güncellenmesi gerekir. Bir liste düzeltilip diğeri unutulursa çalışanlar farklı bilgilerle ilerler. İşletmenin büyümesi bu sorunu görünür kılabilir; fakat tek neden büyüklük değildir. Küçük bir ekipte de bilgi farklı yerlerde tutuluyorsa benzer karışıklık yaşanabilir.

Kendi işinizde şu durumlara bakın: bir kaydın son hâlini bulmak için dosya adına mı güveniyorsunuz, işi takip eden kişi yokken süreç duruyor mu, müşteriye verilen söz başka ekip tarafından biliniyor mu? Bunlar, yeni bir ekrana ihtiyaç olduğunu hemen kanıtlamaz. Fakat çalışma düzeninin kişisel hafızaya ne kadar bağlı olduğunu gösterir. Bir sorunun ne kadar tekrar ettiğini ve düzeltmek için hangi işlerin yapıldığını not etmek iyi bir başlangıçtır.

• Bir bilgi değişince onu birden fazla yerde yeniden yazıyorsanız, hangi kaydın esas alındığı belirsiz olabilir.
• İşlerin durumu yalnızca kişilere sorularak öğreniliyorsa, ortak bir takip düzeni eksik olabilir.
• “Ben gönderdim, karşı taraf görmemiş” konuşması tekrarlanıyorsa, ekipler arasındaki aktarım tamamlanmıyor olabilir.
• Aynı hata düzeltildikten sonra yeniden çıkıyorsa, kişiden bağımsız bir kontrol veya kural gerekebilir.

Bu notları bir hafta gibi işletmenizde gözlem yapabileceğiniz bir süre boyunca tutun. Müşterilerin özel bilgilerini çoğaltmanız gerekmez; olayın türü, etkilenen iş ve düzeltmek için yapılan işlem yeterli olabilir. Sonra en çok rahatsızlık veren sorunu seçin. Bütün işletmeyi aynı anda yeniden tasarlamaya çalışmak yerine, belirli bir işi baştan sona görmek daha uygulanabilir bir başlangıç sağlar.

Yazılım aramadan önce mevcut düzeni sadeleştirin

İlk deneme yeni bir program kurmak olmayabilir. Kullanılan dosyaları listeleyin ve aynı bilgiyi taşıyanları işaretleyin. Güncel müşteri veya sipariş kaydının hangi dosyada tutulacağına karar verin. Çalışanların kendi kopyalarını neden oluşturduğunu sorun: ortak dosyaya ulaşamamak, kendi işini ayırmak, yanlışlıkla veri değiştirmekten çekinmek veya gerekli alanı bulamamak gibi nedenler olabilir. Sebebi anlamadan yalnızca kopyaları kaldırmak işi zorlaştırabilir.

Ortak kayıtta her işe bir tanım, sorumlu ve anlaşılır durum verin. “Devam ediyor” ifadesi çok geniş kalıyorsa müşteri yanıtı bekliyor, malzeme bekliyor veya hazırlamaya aktarıldı gibi gerçek iş karşılıkları kullanabilirsiniz. Durumların sayısını artırmak amaç değildir. Listeye bakan kişi hangi adımı yapacağını ve kime soracağını anlayabilmelidir. Güncelleme yapacak kişi belli değilse en güzel hazırlanmış tablo da kısa sürede eskir.

Excel’in uygun sürüm ve paylaşım koşullarında aynı dosya üzerinde birlikte çalışma imkânı vardır. Bu nedenle her dosya karışıklığını Excel’in yetersizliği diye açıklamak doğru olmaz. Önce kullanılan sürüm, dosyanın tutulduğu yer ve ekipteki çalışma biçimi incelenebilir. Ortak çalışmaya geçmek kopya sorununu azaltabilir; fakat kimin karar vereceği veya hangi işin tamamlandığı gibi soruları kendiliğinden cevaplamaz. Araçla iş kuralını birlikte değerlendirmek gerekir.

Basit bir kontrol: İşi takip eden çalışan bugün izinli olsa, başka biri ortak kayda bakarak müşteriye doğru durum bilgisini verebilir mi? Veremiyorsa eksik olan bilgiyi ve bu bilginin nerede kaldığını bulun.

Hazır bir araç hangi durumda yeterli olur?

İhtiyacınız müşteri görüşmelerini takip etmek, teklifleri toplamak, görev atamak veya belirli tarihlerde hatırlatma almaksa hazır bir çözüm incelenebilir. Seçimi yalnızca özellik listesine bakarak yapmayın. Kendi işinizden bir örneği araca girin ve günlük akışınızı tamamlamayı deneyin. Müşteri kaydı açıldıktan sonra teklife, siparişe veya göreve geçerken aynı bilgi tekrar yazılıyor mu? Çalışanın yapacağı sonraki iş anlaşılıyor mu?

Denemeye sistemi iyi bilen yöneticinin yanında kullanacak çalışanı da katın. Yönetici için yeterli görünen ekran, hazırlama ekibinin ihtiyaç duyduğu bilgiyi göstermeyebilir. Araçta bir özellik bulunması, sizin kullandığınız biçimde çalıştığı anlamına gelmez. Özellikle farklı yetkiler, dosya ekleri ve işin başka bir ekibe aktarılması gibi adımlar denenmelidir. Satın almadan önce yapılacak bu kısa çalışma, kapsamı daha iyi anlamanızı sağlar.

Bir çözümü karşılaştırırken veri aktarımı, kullanıcı yönetimi, destek ve mevcut kayıtların dışarı alınması gibi günlük sahiplik konularını da sorun. İşletmenin verisine nasıl ulaşacağı ve çalışan değiştiğinde hesabın nasıl yönetileceği belli olsun. Hazır çözümle özel geliştirme arasında karar vermek için hazır yazılım ve özel yazılım karar rehberini kullanabilirsiniz. Buradaki ölçüt, kaç özellik bulunduğundan çok gerçek işinizin ne kadarının güvenilir biçimde karşılandığıdır.

Özel yazılım ihtiyacı ne zaman daha belirginleşir?

Aynı işi yapmak için her gün araçlar arasında bilgi taşıyorsanız, işletmenize özgü hesaplama veya onay kuralları sürekli dışarıda kalıyorsa özel geliştirme değerlendirilebilir. Örneğin teklifte verilen koşul, siparişin nasıl hazırlanacağını etkiliyor; fakat hazırlayan ekip bu koşulu göremiyorsa bağlantının nerede kurulacağına bakmak gerekir. Yeni bir programın adı değil, bu bilgiyi doğru kişiye doğru aşamada ulaştırması önemlidir.

Özel yazılım yalnızca bütün sistemi sıfırdan yapmak anlamına gelmez. Mevcut araçların arasındaki eksik bağlantıyı tamamlayan bir bölüm, işletmeye özgü bir hesaplama ekranı veya müşteri talebini doğru işe dönüştüren bir uygulama olabilir. Kapsam, çözülmesi gereken soruna göre seçilmelidir. İşletmenin yıllardır kullandığı bütün dosyaları bir anda kaldırmak zorunlu değildir. Bazı kayıtlar mevcut sistemde kalırken yeni çözüm belirli bir süreci düzenleyebilir.

BiKreatif’in özel yazılım projeleri hizmetinde başlangıç çalışması, işin hangi kısmının standart çözümle karşılandığını ve hangi kısmın işletmeye özel kaldığını ortaya çıkarmalıdır. Teklifte yalnızca “yönetim paneli” yazması günlük ihtiyacı açıklamaz. Hangi bilgi tekrar yazılmayacak, hangi iş unutulmayacak veya hangi karar daha görünür olacak? Bu soruların cevabı, geliştirilecek uygulamanın sınırını tarif eder.

Herkes meşgulken hangi işin beklediğini nasıl görürsünüz?

İşletme sahibi için bir başka güçlük, dolu görünen günün içinde hangi işin ilerlemediğini anlayamamaktır. Bütün açık işleri tek listede saymak her zaman açıklayıcı olmaz. Kısa bir müşteri yanıtı bekleyen işle hazırlık gerektiren büyük bir sipariş aynı yükü taşımaz. Takip düzeninde işin sorumlusu, beklediği adım ve verilmiş teslim sözü görülebilmelidir. Böylece her çalışana aynı durum sorusunu tekrar yöneltmek yerine hangi konuda karar veya destek gerektiği anlaşılır.

• Müşteriden bilgi bekleyen iş: Eksik bilginin ne olduğu ve kimin dönüş yapacağı belli olsun. Takvime yazılmış olması, işin ilerleyebileceği anlamına gelmeyebilir. Başka bir çalışan kaydı açtığında müşteriye aynı soruları yeniden sormadan devam edebilsin.
• İçeride karar bekleyen iş: Fiyat, kapsam veya hazırlık için kimin onay vereceği görünsün. İş herkesin listesinde durduğu hâlde kimsenin üstlenmediği bir görev olarak kalmasın. Karar verildiğinde sonraki kişinin haberdar olması da akışın parçası olsun.
• Başlanabilecek iş: Gerekli bilgi tamamlanmışsa sıradaki görev ve sorumlusu anlaşılsın. Öncelik değişiyorsa bunun nedeni ilgili çalışanlara ulaşsın. Yalnızca müşterinin son mesajına göre sıra değiştirildiğinde daha önce verilen sözler gözden kaçabilir.

Bu ayrım için ilk günden ayrıntılı bir kapasite planlama sistemi gerekmeyebilir. Önce bekleme nedenlerini ortak bir dilde kaydedin. Birkaç örneği ekiple inceleyince sorunun eksik bilgi, onay bekleme veya gerçek kapasite yetersizliği olduğu görülebilir. Sonraki yazılım ihtiyacı da bu gözleme dayanır. Tek bir yoğunluk etiketi altında toplanmış işleri ayrı kararlarla ele almak, proje geliştirmeye daha doğru bir başlangıç sağlar.

Yanlış bilgiyle çalışmayı küçük bir örnek üzerinden görün

Öğretici bir örnek düşünelim: müşterinin yüz adetlik işi hazırlanmaya başlamışken mesajla yüz yirmi adet istediği iletiliyor. Satış ekibi yeni miktarı not ediyor; hazırlayan kişi eski belgeyi kullanıyor. Müşterinin isteğinin kabul edilip edilmediği, ek miktarın ne zaman hazırlanacağı ve fiyatın değişip değişmediği açık değilse yalnızca sayıyı güncellemek sorunu çözmez. İstek ile kabul edilmiş işin ayrı anlaşılması gerekir.

Bir prototipte mevcut sipariş, gelen değişiklik ve yetkili kişinin kararı yan yana gösterilebilir. Müşterinin talebi henüz değerlendirilirken hazırlama ekibi mevcut işi görür. Değişiklik kabul edildiğinde hangi kapsamın nereden itibaren uygulanacağı açıklanır. Bu örneğin amacı işletmeye belirli bir yazılım şeması dayatmak değildir. Satış ve operasyonun aynı iş hakkında farklı şeyler düşünüp düşünmediğini görünür kılmaktır.

Sizin işletmenizde benzer kopukluk fiyat, ürün seçeneği, teslim günü veya görev sorumlusu üzerinde oluşabilir. Görüşmeye böyle bir örnekle gitmek, genel bir “Bütün işlerimizi tek yerde toplayalım” isteğinden daha açıklayıcıdır. Ne olduğu, kimin hangi bilgiyi gördüğü ve beklenen sonucun ne olduğu anlaşılınca çözüm seçenekleri karşılaştırılabilir. Bazı durumlarda küçük bir düzenleme yeterli olur; bazılarında özel bir akış gerekir.

İlk sürüme her şeyi koymadan nasıl fayda sağlarsınız?

En sık karışan bir iş türünü seçin ve başlangıcından tamamlanmasına kadar takip edin. İlk müşteri talebi nereden geliyor, kim değerlendiriyor, kim uyguluyor ve işin bittiği nasıl anlaşılıyor? İlk sürüm bu yolun çalışmasına odaklanabilir. Her departmanın bütün raporlarını aynı anda eklemek yerine çalışanların gerçekten kullanacağı küçük bir akışı tamamlamak daha anlaşılır bir teslim oluşturur.

Bir ilk sürüm listesi, yapılacak ekranların yanında beklenen günlük sonucu da taşımalıdır:

1. Talep bir yere kaydedilecek. Mesaj veya görüşme sonunda işin kaybolmadan hangi kayda geçtiği belli olacak.
2. Sorumlu kişi işi görecek. Kimin değerlendireceği ve hangi bilginin eksik olduğu anlaşılacak.
3. Gerekli karar kayda geçecek. Müşterinin isteği ile işletmenin kabul ettiği kapsam birbirine karışmayacak.
4. İş başka ekibe aktarılabilecek. Sonraki çalışan yeniden mesaj aramadan gereken bilgiye ulaşacak.
5. Bekleyen ve tamamlanan işler ayrılacak. İşletme sahibi bütün işleri tek tek telefonla sormadan genel durumu görebilecek.

Bu liste her işletmede aynı biçimde uygulanmaz. Önemli olan ilk sürümün bir işi gerçekten tamamlamasıdır. Birbirinden kopuk çok sayıda ekranın açılması, günlük düzenin değiştiğini göstermez. Sınırlı kapsamla başlamak, gerekli yetki ve doğru kayıt gibi temel davranışların atlanması anlamına da gelmemelidir. Hangi bilgiyi kimin değiştirebildiği ve yanlış işlemden nasıl dönüleceği baştan düşünülmelidir.

Prototipte neye bakmalı, yazılım ekibine ne sormalısınız?

Prototip, ekibin istediğiniz ekranı çizip çizmediğini görmekten fazlası için kullanılabilir. Çalışanınıza küçük bir görev verin: yeni talebi kaydetsin, eksik bilgiyi fark etsin ve işi sonraki kişiye aktarsın. Siz düğmelerin yerini anlatmadan ilerleyebiliyor mu? Sonraki kişi kaydı açtığında ne yapacağını biliyor mu? Bir işin neden beklediği açıklanabiliyor mu? Bu gözlemler, geliştirmeye başlamadan önce eksik soruları ortaya çıkarır.

İşletme sahibi olarak toplantıda şu üç konuyu özellikle netleştirebilirsiniz: hangi sorun ilk sürümde çözülecek, bunun çalıştığını hangi örnekle göreceksiniz ve hangi konular daha sonra ele alınacak? Bu cevaplar yazılı olduğunda kapsam değişiklikleri de daha anlaşılır konuşulur. Prototiple karar vermenin ayrıntıları için yazılım prototipi rehberine bakabilirsiniz. Deneme sonunda beğenilen ekranlar kadar anlaşılmayan noktalar da kaydedilmelidir.

Teklifi değerlendirirken örnek işi bütün ekiplerle aynı şekilde paylaşın. Birinin yalnızca talep ekranını, diğerinin bütün operasyonu fiyatlandırdığı durumda rakamları doğrudan karşılaştırmak yanıltıcı olabilir. Kayıt aktarımı, eğitim, kullanım desteği ve bakımın kapsamda olup olmadığını sorun. Günlük kullanıcıların sistemi denemesi de teslim planının parçası olsun. Böylece proje, işletme sahibinin onayladığı bir sunumdan çalışanların kullanabildiği bir araca dönüşebilir.

Ar-Ge ve proje geliştirme bu işin neresinde yer alır?

İhtiyaç belli, yöntem biliniyor ve hazır bir düzenleme yeterliyse her işe Ar-Ge demek gerekmez. Araştırma gereken yerde ise belirsizliğin adı konmalıdır. Örneğin eldeki farklı ürün bilgilerinden güvenilir bir teklif hesabı çıkarılıp çıkarılamayacağı veya kesintili bağlantıda çalışan ekiplerin kayıtlarının nasıl birleştirileceği henüz bilinmiyor olabilir. Böyle bir soruyu büyük projeye başlamadan küçük bir denemeyle sınamak değerlidir.

Denemenin sonunda “Bir ekran yaptık” demekten daha somut bir cevap elde edilmelidir: hangi yöntem denendi, hangi koşulda çalıştı, nerede yetersiz kaldı ve sonraki adım ne olacak? Yazılım Ar-Ge çalışması rehberi bu yaklaşımı ayrıntılandırır. Özel yazılım, Ar-Ge ve proje geliştirme aynı çalışmada buluşabilir; ancak araştırma ihtiyacı, yalnızca kullanılan teknolojiye veya projeye verilen isme dayanarak belirlenmez.

Bağcılar’da yazılım ekibi ararken bu ayrım bütçenin ve beklentinin konuşulmasını da kolaylaştırır. Bilinen bir işin geliştirilmesiyle sonucunun henüz araştırılacağı bir deneme aynı teslim sözüyle anlatılmamalıdır. İşletme hangi çıktıyı beklediğini, ekip de neyi sınayacağını bilsin. Araştırmadan öğrenilen sonuç, sonraki geliştirme kapsamına açıkça aktarılmalıdır. Böylece belirsizlik, proje ilerledikten sonra ortaya çıkan sürpriz bir ek iş gibi görünmez.

Yeni sisteme geçerken eski kayıtlar ve ekip ne olacak?

Eski dosyaların tamamını olduğu gibi taşımak her zaman iyi bir başlangıç sağlamaz. Aynı müşterinin farklı yazımları, kullanılmayan ürünler veya neyi anlattığı unutulmuş sütunlar bulunabilir. Önce günlük iş için hangi kayıtların gerekli olduğunu seçin. Yeni sisteme taşınacak bilginin güncelliğini kontrol edecek bir kişi belirleyin. Eski veriyi temizleme işi, yazılım teslim edilirken ilk kez fark edilen görünmez bir sorumluluk olarak kalmamalıdır.

Geçişin ilk döneminde eski ve yeni düzenin hangi amaçla kullanılacağı açık olsun. Bir işi iki yerde ayrı ayrı takip etmek zorundaysanız bu durumun ne zaman biteceğini ve karşılaştırmayı kimin yapacağını yazın. Aksi hâlde iki dosyanın yerini iki sistem alabilir. Eğitimde yalnızca yeni kayıt açmayı değil, hatalı bilgiyi düzeltmeyi, bekleyen işi bulmayı ve çalışan değiştiğinde sorumluluk devretmeyi de deneyin.

İşletme sahibi için ilk değerlendirme sorusu “Kaç ekran yaptık?” olmamalıdır. Çalışan aynı bilgiyi daha az mı yeniden yazıyor, bir işin neden beklediği görülebiliyor mu, müşteri değişikliği doğru kişiye ulaşıyor mu? Bu soruları örnek işler üzerinde cevaplayın. Ölçülmemiş tasarruf veya başarı oranı yazmadan da sistemin nerede yarar sağladığını görebilirsiniz. Eksik kalan noktaları bir sonraki geliştirme için somut görevler hâline getirin.

Başlangıç görüşmesine kişisel bilgileri temizlenmiş bir iş örneği, kullanılan dosyaların kısa listesi ve tekrarlanan üç sorunla gelebilirsiniz. İhtiyacı kapsam belgesine dönüştürme rehberi bu hazırlığı destekler. Günlük işinizde nereden başlayacağınızı değerlendirmek için BiKreatif ile işinize uygun çözümü görüşebilirsiniz. İyi bir başlangıç, işletmenizin en çok zorlandığı işi herkesin anlayacağı biçimde ortaya koymaktır.

Sık sorulan sorular

Excel kullanıyorsak mutlaka özel yazılıma geçmeli miyiz?

Hayır. Dosya düzeni, ortak çalışma ve görev paylaşımı ihtiyacınızı karşılıyorsa mevcut yapıyı iyileştirmek yeterli olabilir. Önce hangi sorunun tekrar ettiğini bulun. Aynı bilginin farklı yerlere yazılması, yetkili kararların izlenememesi veya ekipler arasında bilgi kopması devam ediyorsa başka çözümleri değerlendirin. Karar kullandığınız dosyanın adına göre değil, işin güvenilir biçimde tamamlanıp tamamlanamadığına göre verilmelidir.

Mesajlarla iş takip etmenin nerede sorun çıkardığını nasıl anlarız?

Bir işi seçip başlangıcından tamamlanmasına kadar izleyin. Son bilgiye ulaşmak için kaç konuşmaya dönüldüğünü ve hangi kararın yalnızca bir kişinin telefonunda kaldığını not edin. Mesajlaşma iletişim için kullanışlı olabilir; önemli iş bilgilerinin ortak kayda taşınmaması ise takip boşluğu yaratabilir. Çalışan yokken işin durması veya aynı sorunun tekrar sorulması, bu boşluğun günlük işteki işaretlerindendir.

Hazır araçla özel yazılım arasında nasıl seçim yaparız?

Önce kendi işinizden bir örneği hazır çözümde tamamlamayı deneyin. Gereken alanlar, kararlar ve ekipler arası aktarım makul biçimde çalışıyorsa hazır araç uygun olabilir. İşletmeye özgü kural sürekli dışarıda kalıyor veya aynı bilgi yine elle taşınıyorsa özel geliştirme değerlendirilebilir. Birkaç küçük eksik için bütün sistemi değiştirmekle, temel iş karşılanmamasına rağmen mevcut aracı zorlamak arasında kapsamınıza göre karar verin.

Özel yazılım yaptırmak bütün sistemi sıfırdan kurmak mıdır?

Her zaman değil. Mevcut sistemlerin arasındaki bir bağlantı, işletmeye özgü hesaplama veya belirli bir işin takip ekranı geliştirilebilir. Hangi verinin nerede tutulacağı ve yeni bölümün günlük sürece nasıl katılacağı açık olmalıdır. Küçük kapsam, belirsiz kapsam demek değildir. İlgili işin başlangıcını, tamamlanmasını ve sorun durumunda ne yapılacağını tarif edebiliyorsanız sınırlı bir proje daha anlamlı biçimde karşılaştırılabilir.

İlk görüşmede yazılım ekibine ne göstermeliyiz?

Bir normal iş örneği, bir değişiklik örneği ve tekrarlanan bir sorunun nasıl düzeltildiğini gösteren kayıtlar yararlıdır. Kişisel bilgileri temizleyin; kullanılan dosyaları ve kimin hangi adımı yaptığını not edin. Uzun bir özellik listesi hazırlamak zorunda değilsiniz. Ekip önce işinizi anlamalıdır. Hangi bilginin kaybolduğu veya neden tekrar yazıldığı görülürse gerekli çözümün kapsamı daha doğru konuşulabilir.

Ar-Ge çalışması her özel yazılım projesinde gerekli mi?

Hayır. Bazı ihtiyaçlar bilinen yöntemlerle geliştirilebilir. Ar-Ge yaklaşımı, cevaplanması gereken gerçek bir teknik belirsizlik olduğunda değerlidir. Belirsizliği ve denemenin hangi karara yardım edeceğini açıkça yazın. Kullanılacak teknolojinin yeni olması tek başına araştırmanın amacını anlatmaz. Denemenin sonunda ne öğrenildiği, hangi sınırların görüldüğü ve sonraki geliştirme adımının nasıl değiştiği anlaşılabilmelidir.

Çalışanlar yeni sistemi kullanmazsa ne yapmalıyız?

Önce nedenini bulun. İş için gerekli bilgi eksik olabilir, ekran günlük sıraya uymayabilir veya eski dosya hâlâ resmî kayıt gibi kullanılıyor olabilir. Çalışana aynı bilgiyi iki yerde tutturmak yeni sistemin değerini azaltır. Gerçek görev üzerinden kısa bir deneme yapın ve takıldığı adımı gözleyin. Eğitim eksikliğiyle tasarım veya süreç eksikliğini ayırarak düzeltmek, yalnızca kullanılması gerektiğini söylemekten daha somut bir yoldur.

Bağcılar’da özel yazılım projesine hangi işle başlamalıyız?

İşletmenizde sık tekrarlanan, etkisi açık ve başlangıcıyla sonucu görülebilen bir işi seçin. Tekliften siparişe geçiş, müşteri değişikliğinin aktarılması veya bekleyen görevlerin takibi olabilir. İlk sürümde bu yolu tamamlayıp çalışanlarla deneyin. İhtiyaç netleşince başka bölümler eklenebilir. Başlangıç hedefi bütün işletmeyi tek seferde dönüştürmek değil, önemli bir günlük sorunu gerçekten çözebilen ve sürdürülebilen bir düzen kurmaktır.