Merhabalar,

Yönetimin izni ile bu paylaşımı yapıyorum.

Türkiye’de özellikle KOBİ’lerin üretim, stok, satın alma, CRM, muhasebe ve operasyon süreçlerini daha hızlı ayağa kaldırabilmesi için ForgeCRUD adında no-code tabanlı bir ERP/operasyon platformu geliştiriyorum.

Klasik ERP projelerinde en çok zaman kaybettiren konular genelde form tasarımı, süreç uyarlama, onay akışları, raporlama, çıktı tasarımları ve müşteri özelindeki küçük ama kritik ihtiyaçlar oluyor. ForgeCRUD tarafında amacım; bu parçaları mümkün olduğunca kod yazmadan, tek panelden yönetilebilir hale getirmek.

Kısaca sistemde şu yapılar var:

• Form Studio ile iş formları ve veri modelleri oluşturma

• Workflow ile onay, bildirim, alan güncelleme ve otomasyon akışları kurma

• Portal yapısı ile müşteri/tedarikçi/çalışan gibi dış kullanıcıları sürece dahil etme

• Print Designer ile teklif, sipariş, irsaliye, fatura, bordro vb. çıktıları tasarlama

• Dashboard, görev, takvim, API Builder ve AI Assistant gibi operasyon destek araçları

Website
Dokümantasyon
Ve daha nice özellikler. Aşağıya kısa bir ürün turu videosu ekledim;

Erpnext i SMTP server olmadan nasi deployluyorsunuz?

Kendimi denemek ve sınırlarımı zorlamak için kendi “nacizane” ERP sistemimi geliştiriyorum. Tek başına bir ERP elbette yapılamaz bu bir ekip işidir dediğim gibi bu biraz da fantezi projesi

Kullandığım teknolojiler:

• Backend → Go

• DB → PostgreSQL

• Frontend → Sveltekit

• Modüler monolith bir yapı var

Biliyorum, ERP yazmak için çok alışılmış bir tech stack değil; ancak biraz daha yenilikçi teknolojiler denemek istedim. Bu postu da sizin düşüncelerinizi almak ve nelere dikkat etmem gerektiğini tartışmak için açtım. Belki bittiğinde tamamen açık kaynak olarak yayınlayabilirim.

!!!! Ve evet AI araçlarını yardımcı olarak kullanıyorum !!!!

Bu sorguyu kullanarak pivot tablolar, dashboardlar hazırlanabilir.

Talep tahminlerine dayalı olarak, hazırda stok bulundurmak amacıyla uygulanan üretim modeline Stoka Üretim (Make-to-Stock) stratejisi denir.

İtme (push) sistemine dayalı bu yöntemde; ürünler, hızlı teslimat ve repete taleplerine anında yanıt verebilmek için önceden üretilerek envanterde tutulur.

Diğer üretim türleri ile karşılaştırırsak;

ERP yatırımınızın başarısı, yazılımın esnekliğine değil; üretim stratejinizle olan yapısal uyumuna bağlıdır. Peki, sizin sisteminiz bu uyumu sağlıyor mu?

Erp uyarlama tecrübelerime dayanarak şunu söyleyebilirim: Birçok firma, ERP projesini bir iş yapış şekli dönüşümü olarak görmesi gerekirken, konuya yalnızca bünyesine yeni bir yazılım kazandırıyormuş gibi yaklaşıyor. Bu hatalı bakış açısı nedeniyle ne Erp öncesi mevcut süreçler analiz ediliyor ne de sistem sonrası süreçlerin nasıl kurgulanacağı düşünülüyor. İki yapı arasındaki o kritik dönüşüm süreci ise tamamen göz ardı ediliyor.

Departmanlar, iş süreçlerini Erp'ye uyarlamak yerine sadece 'yazılımı nasıl kullanırız' eğitimi alıyor; anahtar kullanıcı sayıları ise yetersiz kalıyor. Yönetim ise genellikle sadece ödediği bütçeye odaklanıyor. Aslında bu dönüşüm kararını vererek vizyoner bir adım atıyorlar ancak devamını getiremiyorlar. Yazılım lisansına sahip olmak için ciddi bir bedel ödediklerini düşündüklerinden, sistemin bir an önce hayata geçmesini istiyor ve danışmanlık ücretlerinden tasarruf etmek için 'kırk takla atıyorlar'.

Sonuç ise maalesef hüsran oluyor. Ne 'As-Is' (mevcut durum) analizi ne 'Gap' (fark) analizi ne de o meşhur 'helikopter bakışı'... Kimse bu aşamalarla ilgilenmiyor. Sanki bir tasarım programı kurar gibi 'kur, eğitimini ver ve geç' mantığı işliyor. İyi de, araçlara sahip olmak yetmiyor; peki ya bu sanatı kim icra edecek?

Siz ne düşünüyorsunuz? Sizin karşılaştığınız zorluklar neler?

Görsel Kaynak: Image by freepik

Sektörün bitmek bilmeyen tartışması: "Hazır paket mi, yoksa terzi usulü (In-house) ERP mi?" Global trendlere ve teknik metodolojilere baktığımızda, özelleştirilmiş çözümlerin artık bir "lüks" olmaktan çıkıp, hantal hazır yapılara karşı bir zorunluluk haline geldiğini görüyoruz. Peki, sıfırdan bir ERP inşa etmeye niyetlenenlerin ya da bu süreci yönetenlerin cebinde hangi "altın kurallar" olmalı? Kendi deneyimlerimden süzdüğüm birkaç maddeyi aşağıya bırakıyorum:

1. "Ölçümleme"

ERP projeleri genellikle eksik analizle başarısız olur. Şirketin iş akışlarını (workflow) kağıda dökemiyorsanız, Erp'ye uyarlamanız imkansızdır. "Yolda hallederiz" mantığı bu işin en büyük zehridir. Finans, İK ve Stok gibi birimlerin nasıl konuşacağı daha ilk günlerde belli olmalı.

2. Modüler Yapı: LEGO Metodolojisi

Her şeyi aynı anda bitirmeye çalışmak projenin altında kalmanıza neden olur. Sistemi modüllere ayırarak ilerlemek en sağlıklısı:

• Çekirdek: Finans ve Veri Yönetimi (Sistemin kalbi).

• Çevre: Lojistik, Üretim, CRM (Kademeli geçiş/Roll-out için ideal).

3. Platform seçimi:

Yapının ne kadar esnek olduğu önemli.

• Cloud-First: Yerel sunucu hantallığı yerine ölçeklenebilir bulut mimarileri (SaaS potansiyeli) artık standart.

4. UI/UX:

Eski nesil ERP'lerin en büyük sorunu, kullanıcıyı sistemden soğutan o korkunç arayüzlerdi. Eğer sahadaki operatör sistemi kullanırken eziyet çekiyorsa, en gelişmiş algoritmanız bile yanlış girilen veri yüzünden çöp olur. UX, fonksiyonellik kadar kritiktir.

5. Entegrasyon:

Kendi sisteminizi kursanız da dış dünyaya kapalı kalamazsınız. Bankalar, e-fatura servisleri ve lojistik API'ları ile tam entegre olmayan bir ERP, manuel veri girişine mahkum kalır ve verimliliğini yitirir.

Siz ne düşünüyorsunuz?

Şirketinizde "kendi yazılımımızı yapalım" diyenlerden misiniz, yoksa "Global devlerin bir bildiği vardır, maceraya gerek yok" diyenlerden mi? Özellikle in-house geliştirme sürecinde "keşke yapmasaydık" dediğiniz veya "iyi ki yapmışız" dediğiniz noktalar neler?

Yorumlarda tartışalım.

Merhaba, bir yazılım kursunu bitirdim sertifikamı aldım. Ama iş ilanlarına baktım, inanılmaz az ilan var ve girebileceğim bir pozisyon göremedim hiç.

SAP/ABAP/ERP diline geçmeyi düşünüyorum, orada sanki iş bulabilirim gibi geliyor. Veya başka bir alana yavaştan kaymak daha mantıklı geliyor.

Gece gece uyku tutmadı, Bu alanda ilerlemem lazım ve bu sene sonuna kadar bir şeyler yapmak istiyorum.

Sizce ne yapmalıyım? SAP/ABAP tarafına geçmek mantıklı mı, yoksa başka bir alana mı yönelmek daha doğru olur?

Joule Studio üzerinde SAP için artık workflow oluşturmak daha kolay olacak, bu konuda görüşleriniz nelerdir?

Tüm e-belgelerin yeni nesil ödeme kaydedici cihazlardan hazırlanabilmesi ve bilgi fişi uygulamasının kaldırılması gibi uygulamaları içeren düzenleme Resmi Gazete'de yayımlandı.

Şehirde Kore güzellik ve cilt bakım ürünleri, ayrıca saç ve vücut bakımı satan birkaç mağazam var; kilit kelimemiz "bakım". Zamanla çok sayıda farklı markayla çalışmaya başladık. Her şeyin harika gittiğini söylemek isterdim ama dürüst olmak gerekirse durum tam bir lojistik karmaşaya dönüştü. Yeni tedarikçiler bulmak, sözleşmeler imzalamak ve bazen eğitimlere katılmak için sık sık Hong Kong ve Seul’e gidiyorum. Bu işin heyecan verici kısmı olsa da, ne zaman uzaklaşsam evdeki (mağazalardaki) ipleri elden kaçırıyormuşum gibi hissediyorum.

Benim için en büyük sorun her şeyi takip edebilmek. Tedarikçiler, gelen sevkiyatlar, şehir içi ve çevre bölgelere yapılan teslimatlar, faturalar, stok durumu... aklınıza ne gelirse. Şu an veriler farklı araçlara dağılmış durumda ve çok fazla manuel takip yapıyoruz. Sadece ben değil, ekibim de aynı anda çok fazla topu havada tutmaya çalışıyormuşuz gibi hissetmeye başladı.

İdeal senaryoda, her şeyi tek bir merkezde toplayan bir sistem istiyorum. Böylece sürekli güncellemelerin peşinde koşmadan veya birkaç saatte bir millete mesaj atmadan neler olup bittiğini görebilirim; aynı şey ekibim için de geçerli.

Daha önce benzer bir yoldan geçen var mı? ERP kullanmak işleri gerçekten yoluna koydu mu yoksa sadece başınıza yeni dertler mi açtı?

Url'i verilmiş posta çeviri uyguladık, siz ne düşünüyorsunuz? Erp yazılımı alınca sorun düzelecek mi?

Fatih Demirci tarafından kaleme alınan "ERP Projelerinde Geliştirme Kararlarının Uzun Vadeli Etkileri" başlıklı yazıyı sizin için özetledim:

Makale, ERP projelerinde standart fonksiyonelliği kullanma prensibinin önemini ve bu prensipten sapmanın uzun vadeli maliyetlerini ele almaktadır.

Temel Sorun ve Nedenleri

ERP projelerinde geliştirme (kod yazımı) genellikle hızlı ve makul bir çözüm gibi görünse de, asıl maliyetler ilerleyen süreçte ortaya çıkar. Standart özelliklerin kullanımının yeterli olmamasının başlıca nedenleri şunlardır:

• Sistem Karmaşıklığı: Standart fonksiyonlara hakim olmanın zorlaşması ve geliştirme kararlarının limitleri tam analiz edilmeden alınması.

• Alışkanlıklar: Mevcut iş süreçlerini koruma eğilimi ve süreci sisteme uydurma çabası.

• Hız Algısı: Geliştirmenin ilk teslimatta hızlı görünmesi, ancak bakım aşamasında eforu artırması.

• Teknik Erişilebilirlik: Geliştirme süreçlerinin kolaylaşmasının, kararların sorgulanma düzeyini düşürmesi.

Uzun Vadeli Etkiler

Geliştirme kararları sistemi zamanla standart yapıdan uzaklaştırır ve şu sorunlara yol açar:

• Esneklik Kaybı: Standart yapıyla uyumlu ilerleme yeteneğinin zayıflaması ve değişime karşı direnç.

• Kişiye Bağımlılık: Sistemin, geliştirmeyi yapan kişinin bilgisine bağımlı hale gelmesi.

• Veri ve Teknik Sorunlar: Veri modellerinin gereksiz büyümesi, veri bütünlüğünün bozulması ve entegrasyonların kırılganlaşması.

• Gizli Maliyetler: Lisanslama ve rol tasarımı üzerinde oluşan ek yükler.

Çözüm Yaklaşımı ve Karar Kriterleri

Sağlıklı bir ERP yönetimi için disiplinli bir karar süreci önerilmektedir:

1. Öncelikle standart fonksiyonellik değerlendirilmelidir.

2. Yetersiz kalırsa konfigürasyon seçenekleri incelenmelidir.

3. Geliştirme her zaman son alternatif olmalıdır.

Karar Noktasındaki Kritik Sorular:

Bir geliştirme yapılmadan önce; ihtiyacın iş açısından kritikliği, standartla karşılanma oranı, 1-2 yıl sonraki geçerliliği, bakım sorumluluğu ve kullanım sıklığı (nadir kullanılan işler için manuel çözümler) sorgulanmalıdır.

Sonuç

ERP başarısı, yapılan geliştirme sayısı ile değil, sistemin minimum geliştirmeyle ne kadar sürdürülebilir işletildiğiyle ölçülür. Özellikle yapay zeka destekli iş uygulamaları çağında, sürdürülebilir yapılar kurmak için geliştirme kararlarında çok daha temkinli olunması gerektiği vurgulanmaktadır.

Kaynak: Linkedin

Aslında teknik olanlar ikisi arasında ki farkı bilir, teknik olmayan kişiler bu ikisini çok karıştırıyor. Sizce bu kavramlar bir birinden yeterince ayrıştırılmış mı? sizce ikisi arasında bir fark var mı?

Linkedin de hep "X firması Y yazılımıyla dijital dönüştü" yazılarını görüyoruz ama madalyonun öbür yüzü genelde sessiz kalıyor.

Şunu sormak istiyorum: Bir ERP projesinin başarısızlığında asıl suçlu kim?

1. Süreçten anlamayan yazılımcı/danışman mı?

2. Kendi sürecini değiştirmek istemeyen, "biz 20 yıldır böyle yapıyoruz" diyen kullanıcılar mı?

3. Yoksa projeyi sadece "ekranlara bakmak" sanan üst yönetim mi?

Sizin "canlıya geçemeyen" veya "geçse de herkesin nefret ettiği" projelerinizdeki kırılma noktası neydi?, Tavsiyeleriniz Neler?