Çok şubeli işletme yazılımı, farklı konumlardaki ekiplerin aynı işletme düzeni içinde çalışmasını sağlar. Ancak bütün kayıtları tek ekranda toplamak tek başına yeterli değildir. Hangi bilginin ortak olduğu, şubelerin hangi kararlara yetkili olduğu ve merkezle veri paylaşımının nasıl yürüdüğü belirlenmelidir. Aynı ürün iki şubede farklı kodla tutuluyorsa merkezi toplamı görmek zorlaşabilir. Bir kullanıcının başka şubedeki kaydı yanlışlıkla değiştirmesi de günlük işi etkileyebilir. Bu yüzden başlangıçta ekranlardan önce iş sınırları konuşulmalıdır.

İçindekiler

Çok şubeli işletme yazılımı için bir şubenin kullandığı yöntemi hiç incelemeden diğerlerine kopyalamak uygun olmayabilir. Depo yapısı, kullanıcı görevleri ve yerel işleyiş farklı olabilir. Bazı farklılıklar korunmalı, bazıları ortak kurala bağlanmalıdır. Bu rehber dokuz karar üzerinden şube tanımını, merkezi veriyi, yetkileri ve geçiş hazırlığını açıklar. Hazır maliyet veya başarı oranı sunmaz. İşletmenin gerçek süreçleri ve mevcut programları görülmeden bütün şubeler için tek çözüm önerilmez. Amaç, ortak çalışma düzeninin hangi sorularla kurulacağını göstermektir.

Çok şubeli işletme yazılımı ihtiyacınızı anlatırken sadece kaç şubeniz bulunduğunu belirtmeyin. Hangi işlemler ortak, hangileri yerel ve hangi bilgiler merkeze gidiyor sorularını da cevaplayın. Özel yazılım geliştirme görüşmesinde bir normal işlem ve şubeler arasında farklı yürüyen bir örnek hazırlamak yararlı olabilir. Teknik çözümü kendiniz seçmek zorunda değilsiniz. İşin günlük davranışını ve beklediğiniz sonucu açık anlatmak başlangıç için daha değerlidir. Kullanıcılar ve veri kaynakları bu açıklamaya eklenebilir.

Çok şubeli işletme yazılımı için ortak dil kurmak

Şube, depo, kasa ve kullanıcı grubu aynı kavramlar değildir. Bir şubenin birden fazla deposu olabilir; bir depo da birden fazla satış noktasına hizmet verebilir. Bunların aynı listede tek alanla tutulacağı varsayılmamalıdır. İşletmenin gerçek yapısı anlaşılmalıdır. Merkezi raporda hangi birimlerin karşılaştırılacağı ve ürün hareketinin hangi noktada oluştuğu açıklanır. İşletme büyüdüğünde yeni şubenin nasıl ekleneceği de düşünülmelidir. İlk tasarım sadece mevcut isimleri yazmaktan oluşursa sonraki değişiklikler zorlaşabilir.

Çok şubeli işletme yazılımı planında ortak kavramların kısa sözlüğü oluşturulabilir. Şube kodu, depo kodu, transfer durumu ve sorumlu rol gibi alanlar açıklanır. Aynı kelimenin farklı şubelerde başka anlamda kullanılması erken görülmelidir. Merkezin tamamlandı dediği işlem, şube için henüz müşteriye teslim edilmemiş olabilir. Bu fark raporları etkiler. Teknik terimlerle uzun açıklama yazmak şart değildir. Hangi olayın gerçekleştiği ve hangi sonuçla durumun değiştiği günlük dille tarif edilebilir.

Şube planlamasında alınacak 9 karar

1. Birim yapısını tanımlayın

Önce işletmenin konumlarını ve görevlerini çıkarın. Satış noktası, depo, servis noktası veya merkez ofis ayrı birimler olabilir. Hangi işlem hangi birime bağlanıyor? Kullanıcı birden fazla birimde görev alabilir mi? Şube kapanırsa geçmiş kayıtlar nasıl okunacak? Bu sorular iş yapısının anlaşılmasını sağlar. Birimleri yalnızca adres listesi gibi görmek yeterli değildir. Her birimin hangi kayıtların sahibi olduğu ve hangi raporlarda yer aldığı belirlenmelidir. Geçmiş verinin anlamı korunmalıdır.

Çok şubeli işletme yazılımı için yeni şube açılışını da örnek senaryo olarak düşünün. Yeni birimin ürünleri, kullanıcıları ve başlangıç stokları nasıl hazırlanacak? Mevcut kuralların hangileri otomatik uygulanacak, hangileri ayrıca onaylanacak? Her seferinde geliştirici müdahalesi gerekip gerekmediği ihtiyaca göre değerlendirilir. Kullanıcının kendi başına yapacağı işlemlerde yetki sınırı bulunmalıdır. Birim adı değiştiğinde geçmiş kayıtların görünümü ve merkezi raporların kapsamı da konuşulabilir. Tek bir güncel liste, geçmişin bütün bağlamını açıklamayabilir.

2. Ortak ana veriyi seçin

Ürün, müşteri ve tedarikçi bilgilerinin nerede asıl kayıt kabul edileceği belirlenmelidir. Her şube kendi ürününü açıyorsa aynı ürün farklı kodlarla tekrar edebilir. Bütün ürünlerin merkezden açılması da bazı işletmelerde gecikme yaratabilir. Uygun yöntem, gerçek iş akışına göre seçilir. Yerel öneri ve merkezi onay gibi ara düzenler düşünülebilir. Temel soru hangi kaynağın doğru kabul edildiğidir. Bir bilgi aynı anda farklı yerlerde değişiyorsa hangi değişikliğin geçerli olacağı açıklanmalıdır.

Çok şubeli işletme yazılımı ana verisinde eşleştirme çalışması gerekebilir. Eski şube dosyalarındaki kodların ortak kayda nasıl bağlanacağı incelenir. Benzer isimli iki ürün her zaman aynı ürün değildir; aynı ürün de farklı yazılmış olabilir. İşletme kararını gerektiren eşleştirmeler geliştirici tarafından tahminle tamamlanmamalıdır. Belirsiz kayıtlar ayrı listelenebilir. Aktarım öncesi örnek kontrol ve sonrasında sayım yapılabilir. Amaç yalnızca satır sayısını tutturmak değil, ilişkilerin doğru anlamla korunmasıdır.

3. Şube ve merkez yetkilerini ayırın

Kullanıcının hangi birimde hangi işlemi yapacağı açıklanmalıdır. Merkez tüm şubeleri görebilirken yerel kullanıcı yalnızca kendi kayıtlarını yönetebilir. Bazı roller birden fazla birime erişebilir. Görme, oluşturma, değiştirme ve onay verme ayrı yetkilerdir. Bir kullanıcının rapor toplamını görmesi bütün müşteri ayrıntısına erişmesi gerektiği anlamına gelmez. Yetkiler yalnızca ekran menüsüyle sınırlı düşünülmemelidir. Dosya indirme, arama ve doğrudan kayıt bağlantıları da aynı sınırları izlemelidir.

Çok şubeli işletme yazılımı yetkilerinde kullanıcı taşınması ve görev devri önemlidir. Bir kişi başka şubeye geçtiğinde eski kayıtlarına erişim devam edecek mi? Geçici görevlendirme nasıl açılıp kapatılacak? İşten ayrılan kişinin erişimi kimin tarafından kaldırılacak? Bu işlemler günlük iş düzeninin parçasıdır. Yetki çizelgesi güncel tutulmazsa başlangıçta doğru olan yapı zamanla bozulabilir. İşletmenin sorumlusu ve teknik uygulama birlikte tanımlanmalıdır. Kullanıcı hesabını paylaşmak bu sorumluluğu görünmez hale getirebilir.

4. Fiyat ve stok görünürlüğünü belirleyin

Ürün aynı olsa da fiyat veya kullanılabilir stok şubeye göre farklı olabilir. Bunun gerçekten gerekli olup olmadığı iş kuralıyla açıklanmalıdır. Kullanıcı toplam miktarı mı, kendi şubesindeki miktarı mı, başka şubedeki uygun miktarı mı görecek? Rezervasyon ve transfer bekleyen ürünler nasıl ele alınacak? Sadece stok var yazılması hangi koşulu ifade ediyor? Ekrandaki kısa bilginin altında açık hesap bulunmalıdır. Aksi halde satış vaadiyle gerçek hazırlık durumu arasında fark oluşabilir.

Çok şubeli işletme yazılımı fiyatlarında yerel değişiklik yetkisi varsa sınırları belirleyin. Hangi kullanıcı değiştirebilir, hangi durum onay gerektirir ve geçmiş işlemin fiyatı korunacak mı? Ortak fiyat listesinin güncellenmesi bütün açık teklifleri otomatik etkiliyor mu? Bunlar teknik ekip tarafından varsayımla seçilmemelidir. İşletme hangi davranışa ihtiyaç duyduğunu açıklamalıdır. Kullanıcıların farklı durumları örneklerle değerlendirmesi yararlı olabilir. Fiyatı doğru göstermekle ticari onay sürecini yönetmek birbiriyle ilişkili ama ayrı işlerdir.

5. Şubeler arası hareketi açıklayın

Bir ürünün şubeden çıkması ve diğerine ulaşması aynı anda olmayabilir. Transfer hazırlanıyor, yolda, alındı veya fark bildirildi gibi durumlar gerekebilir. Hangi durumların gerekli olduğu gerçek işlemle belirlenir. Gönderenin kaydettiği miktarla alanın saydığı miktar farklıysa ne yapılacağı açıklanmalıdır. Bütün hareketi tek kayıt düzeltmesiyle gizlemek izlemeyi zorlaştırabilir. İşletme açısından sorumluluk, tarih ve açıklamanın hangi aşamada tutulacağı konuşulur. Bu rehber belirli muhasebe işlemi önermez; operasyon akışını anlatır.

Çok şubeli işletme yazılımı transferlerinde iptal ve geri dönüş de değerlendirilmelidir. Ürün hazırlanmadan iptal ile yoldaki transferin iptali aynı davranışı gerektirmeyebilir. Mevcut stok hesabı hangi olayla değişiyor? Merkez hangi aşamayı raporda görüyor? Bu sorular örnek kayıtlar üzerinden kontrol edilebilir. İşin yalnızca normal tamamlanan yolunu tasarlamak günlük istisnaları dışarıda bırakabilir. Uygulama kapsamına göre senaryolar seçilir ve hangi tarafın hangi adımı onaylayacağı belirlenir. Böylece hareketin anlamı kaybolmaz.

6. Veri güncelleme yöntemini seçin

Şubelerin ortak sisteme ne zaman bağlandığı ve verinin ne sıklıkla güncellendiği bilinmelidir. Her işletmenin gerçek zamanlı paylaşım ihtiyacı aynı değildir. Bazı işlemler anlık bilgi gerektirebilir; bazı raporlar belirli aralıklarla yenilenebilir. Kaynakların teknik olanakları ve bağlantı koşulları incelenmelidir. Ekranda son güncelleme görünmesi kullanıcıya yardımcı olabilir. Veri alınamadığında eski bilginin yeniymiş gibi sunulmaması önemlidir. Hata ve boş kayıt durumu ayrı açıklanmalıdır. Gecikmenin iş etkisi değerlendirilmelidir.

Çok şubeli işletme yazılımı bağlantısı kesildiğinde hangi işlemlerin devam edeceği ayrıca düşünülür. Yerel kayıt yapılacaksa yeniden bağlanınca verinin nasıl taşınacağı sorulmalıdır. Aynı kaydın iki yerde değişmesi çakışma yaratabilir. Her sistemin otomatik olarak çevrim dışı çalışacağı varsayılmamalıdır. Bu özellik ayrı kapsam gerektirebilir. İşletmenin önceliği yalnızca mevcut kayıtları okumak veya belirli işlemi sürdürmek olabilir. İhtiyaçlar ayrıldığında uygun teknik seçenekler daha somut değerlendirilir. Bağlantı yokken hangi bilgiye güvenileceği kullanıcıya açıklanmalıdır.

7. Merkezi rapor tanımlarını ortaklaştırın

Şubeleri karşılaştırmadan önce aynı kavramların aynı hesaplandığını doğrulayın. Satış tarihi, teslim tarihi ve ödeme tarihi farklı dönem sonuçları üretebilir. İptaller veya kısmi teslimler şubeler arasında başka biçimde sayılıyorsa merkezi toplam yanıltıcı olabilir. Raporun tanımı ve kapsadığı dönem açıklanmalıdır. Kullanıcı hangi şubenin hangi kayıtlarını gördüğünü bilmelidir. Ortak rapor, farklı süreçleri zorla aynılaştırmak değildir. Anlamlı karşılaştırma için gerekli ortak tanımın bulunmasıdır. Yerel farklılıklar uygun açıklamalarla korunabilir.

Çok şubeli işletme yazılımı raporlarında toplamdan ayrıntıya geçiş yararlı olabilir. Merkez belirli gecikmeyi gördüğünde ilgili kayıtlara ulaşabilir. Ancak yetki sınırları burada da korunmalıdır. Dışa aktarılan dosyalar ekranda görünmeyen bilgileri içermemelidir. Şubeler arası performans karşılaştırması yapılacaksa işlem hacmi ve iş türü gibi bağlamlar düşünülmelidir. Tek sayıya bakarak neden veya çalışan başarısı hakkında kesin hüküm verilmemelidir. Rapor karar araştırmasını destekler; her sonucu kendi başına açıklamaz.

8. Kurulum ve geçiş sırasını planlayın

Bütün şubelerin aynı gün geçmesi her zaman gerekli veya uygun olmayabilir. Önce sınırlı bir birimde deneme yapılması seçenek olabilir. Bunun kapsamı, eski ve yeni sistemin nasıl kullanılacağı ve geçişin ne zaman tamam sayılacağı açıklanmalıdır. Pilot çalışma gerçek bir test düzeni gerektirir; yalnızca uygulamanın açılması yeterli olmayabilir. İşletmenin kullanacağı senaryolar seçilir. Yeni kayıtların hangi sistemde tutulacağı netleşir. Aynı verinin iki farklı yerde sessizce değişmesi sonradan düzeltme işi yaratabilir.

Çok şubeli işletme yazılımı geçişinde kullanıcı eğitimi şubelerin görevlerine göre düzenlenebilir. Herkesin bütün ekranları öğrenmesi gerekmeyebilir. Hangi işlemler ilk gün yapılacak, sorun hangi kanaldan bildirilecek ve kimin desteği alınacak? Bu sorular cevaplanmalıdır. Veri aktarımının sonucu ilgili kişilerce örneklerle kontrol edilir. Hatalı veya belirsiz kayıtların nasıl ele alınacağı anlaşılır olsun. Geçiş planı yalnızca tarih listesi değildir; sorumlular, kontroller ve beklenmeyen durumlarda izlenecek yöntemi de içerir.

9. Yönetim ve büyüme sorumluluğunu belirleyin

Şube düzeni kurulduktan sonra kullanıcılar, fiyatlar ve süreçler değişebilir. Güncel kuralları kim yönetecek? Yeni bir rol veya rapor talebi nasıl değerlendirilecek? Her yerel istek doğrudan ortak sisteme eklenirse bütün işletmenin yapısı gereksiz büyüyebilir. Taleplerin nedeni ve etkisi incelenmelidir. Bazı ihtiyaçlar tek birimde kalabilir, bazıları ortaklaştırılabilir. Karar yetkisi belli olduğunda geliştirme ekibi çelişen talepler arasında tahmin yapmak zorunda kalmaz. Ortak sistemin sahibi iş açısından da tanımlanmalıdır.

Çok şubeli işletme yazılımı bakımında yalnızca teknik sürüm değil, veri ve yetki düzeni de gözden geçirilir. Kapanmış şubeler, kullanılmayan hesaplar ve eski fiyat listeleri günlük kullanımı etkileyebilir. Güncelleme sıklığı işletmenin ihtiyacına göre belirlenir. Her şeyi otomatik silmek uygun olmayabilir; geçmiş kayıtların korunması gerekebilir. Saklama ve erişim koşulları ayrıca değerlendirilmelidir. İşletme büyüdüğünde ilk varsayımların hala geçerli olup olmadığı kontrol edilir. Bir kez kurulmuş yapı, yeni koşullarda değişmeden doğru kalmak zorunda değildir.

Şube yalıtımı ile fiziksel ayrım aynı şey değildir

Şubelerin aynı uygulamada çalışması, her kullanıcının bütün verilere erişeceği anlamına gelmez. Teknik mimari farklı biçimlerde kurulabilir. Ortak veya ayrılmış kaynakların maliyet, yönetim ve veri erişimi açısından farklı etkileri vardır. Microsoft’un çok kiracılı mimari rehberi, paylaşım ile yalıtımın farklı düzeylerde ele alınabileceğini açıklar. Bu, her şubenin teknik olarak ayrı müşteri hesabı sayılması gerektiği anlamına gelmez. İşletmenizin yapısı incelenerek uygun sınır belirlenir.

Çok şubeli işletme yazılımı mimarisinde karar yalnızca teknik isimlerle verilmemelidir. İşletme hangi bilgilerin ortak olacağını ve hangi erişimlerin ayrılacağını söylemelidir. Teknik ekip bunun uygulanma seçeneklerini ve etkilerini açıklayabilir. Kaynak paylaşımıyla kullanıcı yetkisi birbirinin yerine geçmez. Aynı veritabanında doğru yetki kurulabilir; ayrı ortamda da yanlış paylaşım oluşabilir. Seçilen düzenin örnek kullanıcılarla denenmesi önemlidir. İş ihtiyacından bağımsız hazır mimari dayatmak yerine somut veri ve kullanım koşulları üzerinden değerlendirme yapılmalıdır.

Varsayımsal örnek: Merkez depo ve iki satış noktası

Bir merkez depoya bağlı iki satış noktası düşünelim. Bu tamamen varsayımsal örnekte ürün tanımı merkezde ortak, satış fiyatının belirli bölümü yerel yetkiyle yönetiliyor olsun. Satış noktaları merkezden ürün isteyebiliyor, ancak ürünün gönderilmesi ve alınması farklı olaylar olarak kaydediliyor. Merkez toplamı görüyor; yerel kullanıcı yalnızca kendi işlemlerini yönetiyor. Bu yapı her işletmeye önerilen hazır çözüm değildir. İş kurallarının hangi sorularla açıklanabileceğini göstermek için kullanılır.

Çok şubeli işletme yazılımı bu örnekte yoldaki ürünün hangi stokta görüneceğini açıklamalıdır. Satış noktası aynı ürünü yeniden isterse kullanıcı önceki transferi görebilmelidir. Alınan miktar farklıysa açıklama ve kontrol gerekebilir. Merkezi raporun güncellenme zamanı kullanıcıya gösterilir. Varsayımsal senaryoda belirli başarı oranı veya gerçekleşmiş müşteri sonucu bulunmaz. İşletmenin kendi örnekleriyle normal ve istisna işlemleri denemesi, gerçek gereksinimleri netleştirmeye yardımcı olabilir. Kullanılacak yöntem kapsam değerlendirmesine göre belirlenir.

Farklı şube alışkanlıklarını değerlendirmek

Çok şubeli işletme yazılımı planında her yerel farklılığı hata saymak doğru olmayabilir. Bir şube farklı ürün grubu veya müşteri türüyle çalışıyor olabilir. Bazı farklılıklar ise geçmişten kalan dosya alışkanlığıdır. Hangisinin iş gereği olduğu araştırılmalıdır. Kullanıcılara yalnızca yeni sisteme uyun demek yerine mevcut yöntemin nedeni sorulabilir. Ortak kural seçildiğinde etkisi açıklanır. Yerel farklılığın korunması gerekiyorsa bunun raporlara ve eğitim düzenine etkisi düşünülür. Böylece hem ortak yönetim hem gerçek kullanım ihtiyacı birlikte ele alınabilir.

Çok şubeli işletme yazılımı tasarımında temsilci kullanıcı seçimi önemlidir. Yalnızca merkez yönetimle görüşmek yerel işlemlerin ayrıntılarını eksik bırakabilir. Farklı görevleri yapan kişilerin örnekleri toplanmalıdır. Bunun için herkesin bütün toplantılara katılması gerekmez. Kısa süreç görüşmeleri ve temizlenmiş belgeler kullanılabilir. Çelişen kurallar bulunduğunda karar verecek kişi belli olsun. Teknik ekibin iki farklı talebi sessizce birleştirmesi yanlış beklenti yaratabilir. İş açısından geçerli kararın yazılı kaydı ortak referans oluşturur.

Kayıt sahipliği ve geçmişi korumak

Çok şubeli işletme yazılımı içinde bir siparişin açıldığı şube ile teslim edildiği yer farklı olabilir. Kullanıcı başka şubeye geçtiğinde eski işlemin hangi birime ait olduğu değişmemelidir. Bu tür ilişkilere başlangıçta bakılmalıdır. Güncel kullanıcının şubesine göre bütün geçmişi yeniden yorumlamak yanlış rapor üretebilir. Hangi ilişkinin olay anında saklanacağı teknik tasarım konusudur; iş açısından ihtiyaç örneklerle anlatılabilir. İşletmenin geçmiş raporlardan ne beklediği bilinirse seçenekler daha doğru değerlendirilir. Basit görünen birim alanı önemli anlamlar taşıyabilir.

Çok şubeli işletme yazılımı için şube kapanması da senaryo olmalıdır. Kullanıcılar yeni işlem yapmayabilir ama geçmiş belgelere erişim gerekebilir. Şubeyi listeden silmek bütün ihtiyacı karşılamayabilir. Geçmişin korunması, rapor kapsamı ve erişim rolleri birlikte değerlendirilir. Belirli saklama süreleri bu yazıda önerilmez; işletmenin yükümlülükleri ve kullanım ihtiyacı ayrıca ele alınmalıdır. Kapanan birimin verileri otomatik olarak başka birime taşınacaksa bunun anlamı açıkça konuşulmalıdır. Geçmişi korumakla güncel işlem listesini sade tutmak farklı ihtiyaçlardır.

Tekrarlanan kayıtları ve aktarım farklarını yönetmek

Çok şubeli işletme yazılımı için aynı müşteri birden fazla yerde kayıtlı olabilir. Adların benzemesi bu kayıtların kesinlikle aynı kişiye ait olduğunu göstermez. Şirket unvanı değişmiş veya farklı şube aynı merkezi müşteriye hizmet vermiş olabilir. Birleştirme kararının hangi bilgiye dayandığı açıklanmalıdır. İşletmenin kontrol edeceği belirsiz eşleşmeler ayrı tutulabilir. Teknik ekip kayıtları eşleştirmeye yardımcı araç sağlayabilir; ancak iş açısından kimlik kararını varsayımla vermemelidir. Yanlış birleştirme geçmiş işlemlerin anlamını etkileyebilir.

Çok şubeli işletme yazılımı aktarımında kod değişikliği ile kayıt birleştirme ayrı işlemler olabilir. Eski kodların izlenebilmesi gerekebilir. Kullanıcı geçmiş belge numarasını aradığında doğru kaydı bulabilmelidir. Bu ihtiyaç baştan belirtilmezse aktarım yalnızca güncel alanları taşıyabilir. Hangi eski bilgilerin günlük işte kullanıldığı sorulmalıdır. Her alanın taşınması gerekmeyebilir; fakat bırakılan bilginin etkisi bilinmelidir. Kapsam kararı, veri miktarı kadar işin devamını da dikkate almalıdır. Seçilen yöntem örneklerle kontrol edilir.

Merkezi değişikliklerin şubelere yansıması

Çok şubeli işletme yazılımı ortak ürün alanı veya işlem kuralı değiştiğinde bütün birimler etkilenebilir. Merkezde verilen kararın şubelere ne zaman uygulanacağı ve kullanıcılara nasıl açıklanacağı planlanmalıdır. Aynı gün yoğun çalışan birimin değişikliğe hazırlanması gerekebilir. Sadece uygulamanın yeni sürümünü açmak, herkesin yeni kuralı anladığını göstermez. Kısa açıklama, örnek işlem veya görev bazlı gösterim düşünülebilir. Hangi yöntemin gerektiği değişikliğin büyüklüğüne ve kullanıcıların deneyimine bağlıdır. Eski ve yeni davranış farkı anlaşılır olmalıdır.

Çok şubeli işletme yazılımı değişikliklerinde tek şubenin isteği bütün sisteme taşınmadan etkisi incelenmelidir. Talep gerçekten ortak ihtiyaç mı, yoksa yalnızca yerel koşula mı dayanıyor? Ortaklaştırmanın diğer şubelerde gereksiz alanlar veya adımlar oluşturması mümkün olabilir. Yerel yapılandırma veya ayrı görünüm seçenekleri değerlendirilebilir. Her talebin ayrı sistem geliştirmeye dönüşmesi de yönetimi zorlaştırabilir. Bu nedenle iş etkisi ve teknik bakım yükü birlikte konuşulur. Kararın nedeni kaydedildiğinde benzer istekler daha tutarlı değerlendirilebilir.

Şubelerden gelen bulguları ayırmak

Çok şubeli işletme yazılımı kullanıcısı sorun bildirdiğinde şube, rol ve örnek kayıt bilgisi önemlidir. Merkezde çalışan ekranın yerel kullanıcıda farklı görünmesi yetki veya veri kapsamıyla ilişkili olabilir. Teknik inceleme için gereksiz kişisel bilgi göndermek yerine gerekli bağlam verilir. Hangi işlem yapıldı, ne beklendi ve ne görüldü? Bulgunun aynı şubede başka kullanıcıda tekrar edip etmediği de araştırılabilir. Kullanıcıdan teknik teşhis koyması beklenmemelidir. Açık anlatım ve doğru kayıt, incelemeyi başlatmak için yeterli olabilir.

Çok şubeli işletme yazılımı bulgularında kullanım sorusu, yanlış veri ve uygulama hatası farklı sonuçlar doğurabilir. Hepsini tek sorun listesine atmak önceliklendirmeyi zorlaştırır. İnceleme sonrasında sınıflandırma yapılabilir. Şubelerin aynı soruyu tekrar bildirmesi ortak açıklama ihtiyacını gösterebilir. Sadece bir yerde oluşan fark yerel iş kuralından kaynaklanabilir. Kesin neden araştırılmadan kullanıcı veya ekip suçlanmamalıdır. Sonucun ilgili kişilere bildirilmesi ve gerekirse ortak yönergenin güncellenmesi önemlidir. Takip kaydı tamamlandı işaretinin arkasındaki açıklamayı da içermelidir.

Çok şubeli işletme yazılımı bakımında yedek ve geri dönüş sorumlulukları da konuşulmalıdır. Merkezi sistemin ne kadar süre kullanılamamasına işletmenin dayanabileceği değerlendirilir. Hazır süre önermek doğru değildir; iş etkisi ve uygulanabilir yöntem birlikte ele alınır. Yedek dosyanın bulunması geri yüklemenin sorunsuz yapılacağını tek başına kanıtlamaz. Gerektiğinde nasıl kontrol edileceği ve kimlerin görev alacağı açıklanmalıdır. Şube verilerinin hangi kapsamda korunduğu bilinmeli, birim kullanıcılarının kendi kopyalarına güvenerek ortak kayıt düzenini bozmaması sağlanmalıdır.

İşletme için hazırlık dosyaları

Çok şubeli işletme yazılımı görüşmesinde birim listesi, kullanıcı rolleri ve ürün kodu örnekleri yararlı olabilir. Hangi raporların merkezde ve yerelde kullanıldığını da gösterin. İşlem akışında şubeler arasındaki farklılıkları ayrı not edin. Bütün veriyi ilk görüşmede göndermek gerekli olmayabilir. Hassas bilgileri ayırarak küçük örnek kümesi hazırlayabilirsiniz. Kesin olmayan konuları teyit edilecek olarak işaretleyin. Bilinmeyenleri açıklamak, her şeyin hazır görünmesini sağlamaktan daha yararlıdır. İhtiyacın doğru anlaşılması için malzemenin güncel olması önemlidir.

Çok şubeli işletme yazılımı araştıran Maltepe, İdealtepe ve Anadolu Yakası işletmeleri, merkez ve şubelerin günlük işlerinden örnekler üzerinden HD Bilgisayar ile görüşebilir. İletişim numarası 0532 396 34 71, adres Altayçeşme, Oba Çıkmazı No:3, Maltepe, İstanbul’dur. Görüşme yöntemi ve zamanı ayrıca kararlaştırılır. Bölgesel yakınlık belirli sürede kurulum veya sürekli yerinde destek taahhüdü oluşturmaz. İhtiyacın ayrıntısı, mevcut sistemler ve sorumluluklar değerlendirilerek çalışma kapsamı netleştirilir.

Canlı kullanımdan önce kontrol listesi

Çok şubeli işletme yazılımı değerlendirmesinde sadece ortak giriş ekranının açıldığını görmeyin. Farklı kullanıcıların aynı kayıtlar üzerinde ne yapabildiğini deneyin. Şube değişimi, iptal, transfer farkı ve gecikmiş güncelleme gibi durumlar seçilen kapsama göre kontrol edilebilir. Teknik ekip ve işletme hangi senaryoları kimin değerlendireceğini belirlemelidir. Sonuçlarda beklenmeyen fark varsa neden araştırılır. Eski ve yeni veri arasında yapılan örnek karşılaştırma, günlük kullanıma geçmeden önce yanlış anlamaları ortaya çıkarabilir.

• Şube, depo ve kullanıcı ilişkileri açık mı?
• Ürün ve müşteri için asıl kayıt kaynağı belli mi?
• Görme, değiştirme ve onay yetkileri ayrılmış mı?
• Fiyat ve stok bilgilerinin anlamı açıklanmış mı?
• Transferin çıkış, yol ve kabul aşamaları net mi?
• Güncelleme gecikmesi kullanıcıya gösteriliyor mu?
• Merkezi raporlar ortak tanımlara dayanıyor mu?
• Geçiş, eğitim ve kontrol sorumluları belli mi?
• Yeni şube ve kapanış senaryoları değerlendirildi mi?

Sık sorulan 6 soru

Bütün şubeler aynı ekranları mı kullanmalı?

Görevler ve ihtiyaçlara bağlıdır. Ortak veri tanımları korunurken farklı rol ve görünümler düşünülebilir. Çok şubeli işletme yazılımı herkese bütün bilgiyi göstermek anlamına gelmez. Yerel kullanıcı kendi işlemlerine, merkez ise uygun toplam ve ayrıntılara erişebilir. Hangi farklılığın iş gereği olduğu araştırılmalıdır. Sadece eski alışkanlık nedeniyle ekranları çoğaltmak da doğru olmayabilir. Tasarım, gerçek kullanıcı örnekleriyle değerlendirilmelidir.

Her şube için ayrı sunucu gerekir mi?

Bu otomatik bir gereklilik değildir. Teknik mimari ihtiyaç, erişim sınırları ve yönetim koşullarına göre değerlendirilir. Ortak ve ayrılmış kaynakların farklı etkileri vardır. Çok şubeli işletme yazılımı için önce hangi verinin ortak olacağını açıklayın. Sonra teknik seçenekleri ve sorumlulukları konuşun. Kaynağın fiziksel yeri tek başına doğru yetkilendirme sağlamaz. Örnek kullanıcılarla erişim kontrollerinin denenmesi önemlidir.

İnternet kesildiğinde işlemler devam eder mi?

Bu özellik tasarlanmışsa belirli işlemler sürdürülebilir; bütün uygulamalar için varsayılmamalıdır. Hangi işlemin devam edeceği ve hangi verinin yerelde bulunacağı açıklanmalıdır. Yeniden bağlanınca kayıtların nasıl taşınacağı ayrıca değerlendirilir. Çok şubeli işletme yazılımı için çevrim dışı kullanım ayrı kapsam olabilir. Sadece ekranın açılması yeni işlemin güvenle kaydedildiğini göstermez. Kullanıcının bağlantı ve eşitleme durumunu anlaması gerekir.

Şubeler farklı fiyat kullanabilir mi?

İş ihtiyacı ve kapsamına göre böyle bir düzen düşünülebilir. Kimin değiştireceği, hangi onayın gerekeceği ve geçmiş işlemlerin nasıl korunacağı açıklanmalıdır. Ortak fiyatla yerel fiyat ilişkisi belli olsun. Her şubenin farklı fiyat kullanması zorunlu değildir. Kullanıcı ekranında görülen fiyatın hangi listeye dayandığı anlaşılmalıdır. Açık tekliflerin yeni fiyat değişikliğinden etkilenip etkilenmeyeceği de örneklerle değerlendirilmelidir.

Eski şube dosyaları nasıl taşınır?

Önce kodlar, alanlar ve kayıt ilişkileri incelenir. Aynı ürün veya müşterinin farklı kayıtlarla tutulması eşleştirme gerektirebilir. İşletme kararı isteyen bilgiler tahminle birleştirilmemelidir. Çok şubeli işletme yazılımı aktarımında örnek deneme ve sonuç kontrolü planlanabilir. Hangi kayıtların taşınacağı ve hangi dönemi kapsayacağı ayrıca belirlenir. Satır sayısının eşit olması bütün ilişkilerin doğru aktarıldığını tek başına kanıtlamaz.

İlk görüşmeye ne hazırlamalıyım?

Çok şubeli işletme yazılımı için birimlerin listesini, temel kullanıcı görevlerini ve şubeler arasında farklı yürüyen bir işlemi hazırlayın. Ürün kodu, transfer ve rapor örnekleri yardımcı olabilir. Hassas verileri ayırmanız uygundur. Teknik mimariyi kendiniz belirlemek zorunda değilsiniz. Günlük işin nasıl yürüdüğünü ve merkezi yönetimden ne beklediğinizi açıklayın. Ardından veri, yetki, rapor ve geçiş başlıkları birlikte değerlendirilebilir.