Yazılım

Teklif, Üretim ve Sevkiyat Aynı Dosyaya Bakarak Çalışsın

Bir teklifin fiyatı muhasebede, teknik ayrıntısı üretimde, teslim tarihi sevkiyatta konuşulunca her birim işin yalnızca bir parçasını bilir. Notlar dağınık durdukça dosyanın nerede beklediğini öğrenmek için telefon açmak gerekir. Ortak kaydın her birim için neyi göstereceğini konuşarak yazılım kapsamını bu dağınıklığın üzerine kuruyoruz.

Size özel bir sistem tasarlamadan önce işin sahada nasıl yürüdüğünü adım adım çıkarıyoruz. Servis tarafından bir örnek verelim: arıza çağrısı alınır, teknisyen atanır, parça beklenir, müşteri aranır. Ekranda hepsi tek bir “açık” etiketiyle görünürse parça bekleyen kayıtla teknisyen bekleyen kayıt birbirinden ayırt edilemez.

Yeni bir uygulama yazmak her zaman ilk seçenek değildir. Kullandığınız muhasebe programının bir modülü ya da iyi kurgulanmış bir tablo sorunun bir bölümünü zaten çözüyor olabilir. Bu yüzden bugünkü araçlarınızı tek tek açıp neyi karşıladıklarını, hangi noktada sizi elle takibe mecbur bıraktıklarını birlikte inceliyoruz. Özel geliştirmeye ancak bu boşluk netleştiğinde karar veriyoruz.

  • Teklifin birimden birime geçerken izlediği yol
  • Her birimin ortak dosyada göreceği bilgiler
  • Bugünkü araçların neyi çözüp neyi çözemediği
  • Hazır araç ile özel geliştirme arasındaki tercih

Kayıt Formunda İlk Anda İstenecek Alanlarla Sonrakileri Ayıralım

Müşterinin yanında kayıt açan bir teknisyen uzun bir formla karşılaşırsa alanların çoğunu boş geçer ya da aklına gelen ilk seçeneği işaretler. Ama kaydın hangi müşteriye ve hangi cihaza ait olduğu girilmezse dosya daha ilk günden sahipsiz kalır. Formu bu iki riski tartarak kuruyor, zorunlu alanları en aza indirip kalan bilgileri işin sonraki adımlarına bırakıyoruz.

Masa başında alan listesi yazmak yerine sizden geçmiş bir satın alma talebini açmanızı isteriz. O talep onaylanırken kim neye baktı, tedarikçi seçilirken hangi bilgi arandı, bütçe kontrolü nerede yapıldı? Bu cevaplar, formdaki her alanın hangi karara dayanak olacağını ortaya koyar.

Müşterinin vergi numarası ya da adresi muhasebe programında zaten kayıtlıysa aynı bilgiyi forma elle yazdırmanın anlamı yoktur; oradan çekilip çekilemeyeceğine bakarız. Formun her şey yolunda giderken nasıl davranacağı kadar, kullanıcı yanlış firmayı seçtiğinde ya da girişi yarıda bıraktığında ne olacağı da tasarımın konusudur.

  • Kayıt açılırken istenecek asgari bilgiler
  • Formdaki alanların karar sürecindeki karşılığı
  • Başka programlarda duran bilginin çekilmesi
  • Yarım ya da hatalı girişte gösterilecek uyarı

Durum Adları Birimden Birime Anlam Değiştirmesin

Satış, müşteri teklifi kabul edince kaydı onaylı sayar; üretim ise çizim kesinleşmeden dosyaya dokunmaz. Aynı etiket farklı okununca malzeme siparişi ya erken verilir ya da boşuna bekletilir. Aşama adlarını ekiplerinizin kendi kelimeleriyle koyuyor, her adımın hangi olayla açılıp hangi koşulla kapandığını ortak bir sözlükte yazıyoruz.

Ödeme teyidi gelmeden sevkiyat başlatılabilir mi? Müşteriden imzalı form beklenirken dosya satışta mı durur, operasyonda mı? Bu tür kuralları varsayıma bırakmıyor, ekiplerinizle tek tek konuşup verilen kararları yazılım analiz notlarına madde madde işliyoruz. Kurallar yazılı olduğunda yeni başlayan bir çalışan da aynı sırayı izler.

Onaylanmış bir satın alma talebi bütçe değişince geri çekilebilir. O noktada ilk onayı kimin, hangi gerekçeyle verdiği kaybolursa aynı tartışma baştan yaşanır. Aşama her değiştiğinde tarihin, işlemi yapan kişinin ve açıklamanın saklanıp saklanmayacağını kapsam hazırlanırken kararlaştırıyor, bu geçmişi kimlerin görebileceğini de aynı anda belirliyoruz.

  • Ortak sözlükte tanımlanan aşamalar
  • Ekiplerle konuşulup yazılan kurallar
  • Geri çekilen onayda ilk gerekçenin saklanması
  • Kimin neyi ne zaman değiştirdiği

Her Dosyanın Eksiksiz Gelmediğini Baştan Kabul Edelim

Her kaydın eksiksiz doldurulması beklenemez. Telefonla alınan bir siparişte teslim adresi sonradan netleşir, fatura bilgisi ise hiç verilmemiş olabilir. Bu dosyaları dışarıda bırakmak yerine kimin önüne düşeceklerini ve hangi bilgi girilmeden ilerlemelerine izin verilmeyeceğini akışın parçası olarak tasarlıyoruz. Bir başka örnek sipariş kalemleridir: ürünlerden biri stokta yoksa ve ayrıca gönderilecekse, siparişin tamamına tek bir aşama vermek depoyu da müşteri temsilcisini de yanıltır. Kararın sipariş başlığında mı, her satırda mı tutulacağını bu örnekler üzerinden sizinle seçiyoruz.

Bazı denetimleri sisteme bırakmak mantıklıdır: stoktan fazla çıkış ya da geçmiş bir teslim tarihi girildiğinde ekran hemen uyarabilir. İndirim oranının makul olup olmadığı gibi yoruma açık konular ise bir yöneticinin onayına gider. Aynı sipariş ikinci kez girilirken önceki kaydı gösterip onay istemek, işi durdurmadan hatayı yakalar.

Vadesi geçmiş borcu olan bir müşteriye yine de sevkiyat yapılması gerekebilir; ama bu kararı herkes veremez. Böyle bir istisnanın hangi unvana tanındığını ve onay verilirken gerekçe yazmanın zorunlu olup olmadığını netleştiriyoruz. Test aşamasında da yalnızca olağan siparişleri değil, bu tür onaylı sapmaları da tek tek deniyoruz.

  • Eksik gelen siparişin hangi masaya düşeceği
  • Ekran uyarısı ile yönetici onayının sınırı
  • Aynı siparişin ikinci kez girilmesinde uyarı
  • Gerekçesi yazılan onaylı istisnalar

Depo Görevlisi ile Muhasebecinin Ekranı Aynı Olmak Zorunda Değil

Muhasebeci bir siparişte fiyat ve vade bilgisine bakarken depodaki çalışan için ürün, adet ve raf yeri yeterlidir. Rolleri kurarken unvanlardan değil, kişilerin gün içinde hangi ekranda ne yaptığından yola çıkıyoruz. Bir kişinin birden fazla role sahip olabileceği durumlar da bu aşamada konuşulur.

Bir bölge temsilcisinin yalnızca kendi müşterilerini görmesi ya da bir stajyerin kayıt açabilmesi ama silememesi, menüden birkaç bağlantıyı gizleyerek sağlanamaz. Adres çubuğuna doğru bağlantıyı yazan biri gizlenmiş sayfaya ulaşabiliyorsa kural işlemiyor demektir. Bu nedenle her kısıtlamayı yazılım tarafında, veri istenen her noktada ayrıca denetliyoruz.

İşten ayrılan birinin hesabı hâlâ açıksa ya da izindeki meslektaşının yerine bakan çalışan gerekli ekranlara ulaşamıyorsa sorun teknik değil, sahiplik sorunudur. Bu yüzden kullanıcı tanımlama, yetki değiştirme ve hesap kapatma adımlarını kimin yapacağını teslimden önce belirliyoruz. Tek şifrenin birkaç kişi arasında paylaşıldığı düzende işlemlerin kime ait olduğu da anlaşılamaz.

  • Günlük işe göre çizilen yetki haritası
  • Kayıt açma, düzenleme ve silme ayrımı
  • Menü gizlemenin ötesinde uygulanan kısıt
  • Ayrılan çalışanın hesabını kapatacak kişi

Kullanıcı Güne Kendisini Bekleyen İşlerle Başlasın

Sistemi açan bir satın alma uzmanı önce onayını bekleyen talepleri, ardından tedarikçiden dönüş gelmemiş olanları görmek ister. Tüm kayıtları tarih sırasıyla döken genel bir liste bu ihtiyaca cevap vermez. Giriş ekranlarını bu yüzden rol bazında düşünüyor, her kullanıcı grubuna o gün harekete geçmesi gereken kayıtları ayrı bölümler hâlinde sunuyoruz.

Kayıt detayını açan kişinin aradığı genellikle üç şeydir: dosya hangi aşamada, dikkat edilmesi gereken bir not var mı ve şimdi ne yapmalı. Bu sorulara cevap veren alanları sayfanın üst kısmında toplarken ikincil bilgileri sekmelere ayırıyoruz. Kaydedilmemiş bir düzenlemeden çıkılırken değişikliklerin kaybolacağı da kullanıcıya hatırlatılır.

Tasarım aşamasında ekranlar kısa firma adları ve düzgün kayıtlarla hep güzel görünür. Oysa uzun unvanlı bir şirket, hiç not girilmemiş bir dosya ya da çok uzun bir sipariş listesi aynı sayfayı bambaşka gösterir. Prototipi bu tür verilerle deniyor, sahada telefon ya da el terminali kullanılıyorsa aynı işi o cihazda da tekrarlıyoruz.

  • Role göre hazırlanan giriş ekranları
  • Kritik bilgiyi üstte toplayan detay sayfası
  • Kaydedilmemiş değişiklik için hatırlatma
  • Uzun ad ve kalabalık listeyle denenen prototip

Belgeleri ve Görselleri Kaydın İçinde Toplayalım

Teknisyenin çektiği arıza fotoğrafı kendi telefonunda, müşterinin gönderdiği fatura bir e-posta kutusunda kaldıkça servis dosyası eksik kalır. Ekleri ilgili kayda bağlarken hangi dosya türlerinin gerektiğini, kimlerin görebileceğini ve bir belgenin neden yüklendiğini not etmenin gerekip gerekmediğini birlikte kararlaştırıyoruz.

Telefonla çekilmiş büyük bir görsel ya da açılamayan bir dosya türü yüklenmeye çalışıldığında kullanıcıya ne söyleneceği baştan yazılmalıdır; yavaş bağlantıda yüklemenin sürdüğünü gösteren bir işaret de gerekir. Onaylanmış bir dosyadaki fatura sonradan yenisiyle değiştirilirse onayın geçerli kalıp kalmayacağı da yazılım kuralları arasında yer alır.

Hasar fotoğraflarını inceleyen biri için her görseli ayrı ayrı indirmek vakit kaybıdır; tarayıcıda büyüterek bakabilmek işi hızlandırır. Görsellere müşteri bilgisi de eşlik ediyorsa indirme hakkı daha dar bir gruba verilebilir. Dosyaların nerede tutulacağını ve eski eklerin ne zaman arşivleneceğini de teslimden önce konuşuyoruz.

  • Servis dosyasının içinde duran ekler
  • Hatalı dosya türünde kullanıcıya yol gösterme
  • Faturası değişen kayıtta onayın durumu
  • Tarayıcıda büyütme ve sınırlı indirme hakkı

Uyarılar Doğru Kişiye, Veriler Doğru Programa Gitsin

Her güncellemede tüm ekibe e-posta giden bir düzende bildirimler kısa sürede görmezden gelinmeye başlar. Önce hangi gelişmenin kime iş çıkardığını listeliyoruz: ödeme teyidi muhasebeyi, parça gelişi teknisyeni ilgilendirir. Sadece haber veren mesajlarla yanıt bekleyenleri de başlık ve görünümleriyle birbirinden ayırıyoruz.

Muhasebe programınıza, e-ticaret altyapınıza ya da kargo firmasının sistemine bağlanmadan önce o tarafın teknik dokümanını ve size tanıdığı erişim türünü okuyoruz. Bazı servisler sipariş listesini dışarı verir ama gönderi durumunu güncellemenize izin vermez; bazıları bu imkânı yalnızca belirli paket veya sözleşmelerde açar. Bu yüzden “entegrasyon yapılır” demek yerine her aktarımı ayrı bir satır olarak yazıyor, karşısına test ortamında denenip denenmediğini ve hangi izinle çalıştığını not ediyoruz. Denemesi yapılamayan bir aktarım kapsamda açıkça belirsiz olarak işaretlenir ve üzerine plan kurulmaz.

Kargo servisi bir süre yanıt vermediğinde sipariş ekranı donmamalı, gönderi bilgisi de sessizce eski hâliyle kalmamalıdır. Son güncelleme saatini göstermek, aktarımı sıraya alıp yeniden denemek ya da sorumluya haber vermek arasından işin aciliyetine uyanı seçiyoruz. Bir adres hem sizde hem karşı sistemde değiştirilebiliyorsa hangisinin esas alınacağını da baştan yazıyoruz.

  • Gelişmeyle ilgili kişiye giden uyarı
  • Yanıt bekleyen mesajın ayrı görünmesi
  • Test ortamında denenerek kapsama giren aktarım
  • Servis kesintisinde sıraya alınan aktarımlar

Eski Tablolardaki Kayıtları Yeni Sisteme Temizleyerek Geçirelim

Aynı tedarikçinin bir satırda kısaltmayla, diğerinde tam unvanıyla yazılması insan gözü için sorun değildir; aktarımda ise iki ayrı firma doğar. Tarih sütununa yazılmış notlar ya da boş müşteri kodları da benzer karışıklık yaratır. Taşımadan önce dosyanızdan bir kesit alıp bu sorunları listeliyor, düzeltilecekleri birlikte ayırıyoruz.

Satır sayısının eski dosyayla aynı çıkması aktarımın doğru olduğunu göstermez. Bir siparişin yanlış müşterinin altına düşmesi ya da faturanın başka kayda eklenmesi sayılarla fark edilmez. Bu yüzden rastgele seçilen kayıtları eski ve yeni ekranda yan yana açıyor, yazılım geçişinin kalan kısmını bu kontrolün sonucuna göre planlıyoruz.

Taşıma birkaç gün sürecekse satış ekibinin bu arada teklif hazırlamayı bırakması beklenemez. Eski tabloya o günlerde eklenen kayıtların sonradan nasıl alınacağı, yeni sisteme hangi sabah tamamen geçileceği ve eski dosyanın ne zaman salt okunur yapılacağı önceden takvime bağlanır. Ekiplerin iki araç arasında kalıp aynı işi iki kez girmesini bu şekilde önlüyoruz.

  • Dosyadan alınan kesitte bulunan sorunlar
  • Farklı yazılmış firma adlarının birleştirilmesi
  • Eski ve yeni ekranda yan yana karşılaştırma
  • Takvime bağlanan geçiş ve eski tablonun kapanışı

Panelde Her Grafiğin Cevapladığı Bir Soru Bulunsun

Bir yönetici pazartesi sabahı panele baktığında hangi birimde iş biriktiğini, geçen hafta kaç talebin kapandığını ya da hangi müşterinin dönüş beklediğini öğrenmek isteyebilir. Rapor ekranını bu tür somut sorular üzerinden kuruyor, hiçbir soruya cevap vermeyen göstergeleri panele eklemiyoruz.

“Bu ay tamamlanan servis” sayısı, geçen ay açılıp bu ay kapanan kaydı içerir mi? İptal edilip yeniden açılan bir talep iki kez mi hesaba girer? Aynı veriden farklı sonuç çıkaran bu ayrıntıları kendi başımıza karara bağlamıyoruz; her göstergenin hangi tarihi ve hangi aşamaları esas aldığını sizinle yazılı olarak netleştiriyoruz.

Bölge bazında satış toplamını gören bir müdür, rakamın ardındaki siparişlere inmek ya da listeyi tabloya aktarmak isteyebilir. Bu geçişlerde yetkiler de korunmalıdır; bir temsilci dışa aktarım yoluyla başka bölgenin verisine ulaşmamalıdır. Teslimden önce bir ayın rakamlarını sizin tuttuğunuz kayıtlarla karşılaştırıp farkları kaynağına kadar izliyoruz.

  • Somut yönetim sorularına dayanan göstergeler
  • Yazılı olarak kararlaştırılan hesap kuralı
  • Dışa aktarımda da geçerli olan yetkiler
  • Kendi kayıtlarınızla karşılaştırılan rakamlar

Sistemi Teslim Almadan Önce Ters Giden Durumları da Sınayalım

“Beğendik, tamam” demek kabul için sağlam bir ölçü değildir. Projenin başında, örneğin bir satın alma talebinin girilip bütçe onayından geçmesi ve tedarikçiye iletilmesi gibi uçtan uca akışları senaryo olarak yazıyoruz. Her adımın yanına ekranda ne görülmesi gerektiği not edilir; teslim günü bu liste tek tek işaretlenir.

Senaryoların bir kısmı bilerek yanlış yürütülür: tutar alanına harf yazılır, yetkisiz hesapla onay denenir, aynı form iki kez gönderilir. Bu denemeleri çalışanlarınızın da yapması, yazılım tarafında öngörülmemiş alışkanlıkları ortaya çıkarır. Bulunan sorun “çalışmıyor” diye değil, hangi adımda ne beklenip ne görüldüğüyle kaydedilir.

Testte “şu rapora bir sütun daha eklensin” isteği ile “onay düğmesine basınca kayıt değişmiyor” bildirimi aynı listeye düşebilir. Birincisi yeni bir taleptir, ikincisi anlaşılan kapsamın eksiğidir; ikisini karıştırmak teslim tarihini belirsizleştirir. Her maddeyi türüyle birlikte kaydediyor, düzeltilenleri sizinle yeniden deniyor, sonraya kalanları ayrı listede tutuyoruz.

  • Adım adım işaretlenen kabul listesi
  • Bilerek yanlış yürütülen test adımları
  • Kendi çalışanlarınızın yürüttüğü senaryolar
  • Türüne göre ayrılan geri bildirimler

Sunucu, Yedek ve Hesapların Sorumlusu Baştan Belirlensin

Canlıya geçişten aylar sonra alan adının süresi dolduğunda ya da e-posta servisinin kotası aşıldığında kimin haberdar olacağı belli değilse küçük bir sorun işi durdurabilir. Barındırma hesabının kimin adına açılacağını, yedeklerin nerede tutulup ne sıklıkla denetleneceğini ve dış servislerin faturalarını kimin izleyeceğini teslim belgesine yazıyoruz.

Teklifimizde ilk sürümün içeriğini, teslimin hangi belgelerle yapılacağını ve destek döneminde hangi işlerin karşılanacağını ayrı ayrı yazarız. Kullanım başladıktan sonra gelen yeni bir istek veritabanı yapısına ya da mevcut raporlara dokunabilir. Bu yüzden her ek talebin etkisini önce inceliyor, yazılım üzerinde değişiklik yapmadan kapsamını sizinle netleştiriyoruz.

Somut bir örnekle başlamak işi hızlandırır. Ekibinizin her hafta elle birleştirdiği bir tabloyu ya da “bu dosya nerede kaldı” sorusunun en sık sorulduğu işi getirmeniz yeterli. Onu birlikte adım adım açalım; hangi aşamanın ekran, hangisinin kural, hangisinin başka bir programla bağlantı gerektirdiğini masada görelim ve projeyi bu örnek üzerinden şekillendirelim.

  • Alan adı ve barındırma takibinin sahibi
  • Destek döneminde karşılanacak işler
  • Ek taleplerin önce etki analizinden geçmesi
  • Elle tutulan bir tablodan başlayan proje

Proje Öncesi Merak Edilen Konular

Gerekmez; elinizde böyle bir belge olmaması bir eksiklik sayılmaz. Bugün işin nasıl yürüdüğünü, nerede tıkandığını ve değişince neyin farklı olmasını istediğinizi anlatmanız başlangıç için yeterlidir. Teknik şartnameyi bu konuşmaların ve birlikte incelediğimiz örnek kayıtların ardından biz hazırlayıp onayınıza sunuyoruz. Böylece ihtiyaç anlaşılmadan ekran tasarımına geçilmemiş olur.

Cevabı, kullandığınız ürünün dışarıya ne kadar erişim tanıdığı belirler. Program adını ve paketinizi paylaştığınızda dokümanını inceleyip hangi bilgilerin okunabildiğini, hangilerinin güncellenebildiğini çıkarıyoruz. Sağlayıcıdan ek izin ya da farklı bir paket gerekiyorsa bunu da önceden belirtiyoruz. Küçük bir deneme bağlantısıyla doğrulanmayan bir aktarımı teklife yazmıyoruz.

Evet. Örneğin satış siparişi girer, depo aynı kayıtta hazırlık bilgisini işaretler, muhasebe ise faturayı bağlar; her birim yalnızca kendi bölümünü düzenler. Sıra bir birimden diğerine geçtiğinde ilgili kişiye bildirim gider ve kaydın hangi aşamada beklediği herkes için aynı şekilde görünür. Hangi bölümün hangi alanı göreceği projenin başında sizinle belirlenir.

Taşınabilecek olanla olmayanı dosyalarınızın içeriği belirler. Yıllar içinde sütunların anlamı değişmiş, bazı bilgiler not hücrelerine sıkıştırılmış olabilir. Dosyalarınızdan bir kesit alıp yeni yapıdaki alanlarla eşleştiriyor, karşılığı olmayan bilgileri ayrıca işaretliyoruz. Bu tabloyu birlikte gözden geçirip neyin aynen taşınacağına, neyin elden geçirileceğine ve neyin arşivde kalacağına sizinle karar veriyoruz.

Eğitimin biçimini ve süresini teklif aşamasında sizinle birlikte belirliyoruz. Genel bir menü turu yerine her rolün kendi günlük işini deneme ortamında gerçekçi kayıtlarla baştan sona yapmasını tercih ediyoruz. Sistem ayarlarını yönetecek kişiyle kullanıcı ekleme ve yetki tanımlama gibi konular ayrıca ele alınır. Kullanım başladıktan sonra karşılaşılan bir sorunun kime, hangi bilgilerle iletileceği de yazılı olarak paylaşılır.

Evet, ancak her yeni modül tek başına ele alınır. Örneğin sipariş takibine sonradan servis kayıtları eklenmek istendiğinde müşteri tablosunun, yetki gruplarının ve raporların bundan nasıl etkileneceğine bakılır; bazen bir ayar yeterli olur, bazen kapsamlı bir geliştirme gerekir. Şube açmak ya da bayi ağı kurmak gibi bir planınız varsa bunu ilk görüşmede söylemeniz, altyapının baştan buna uygun seçilmesini kolaylaştırır.