Yazılımınızı satın almanın mı yoksa geliştirmenin mi Ebedi Sorusu (James Monaghan)

Tebrikler. Bir sorununuz, bir projeniz, bütçeniz ve teslim tarihiniz var. Ona ceset atmak yerine, çözüm yazılımdır, ancak şimdi inşa etmeye veya satın almaya karar vermelisiniz, soru bu. Yoksa öyle mi? Kesin bir karar olduğundan artık emin değilim.
Gerekli olan sistemi kodlamak için kurum içi programcıları işe almaya başvurmak için kullanın ve satın alınabilen ve çalıştırılabilen hazır ürünlere atıfta bulunarak satın alın. Muhasebe sistemleri, Ticaret sistemleri, CRM, Raporlama,
Ödünç Verme, Koleksiyonlar, CLM, vb. Artık bir şeyler inşa etmenin kodlama deneyimi gerektirmediği düşük kodlu bir ortamda yaşıyoruz. Sürükle ve bırak olabilir. Bunu, son derece özelleştirilmiş hale gelen raf çözümlerini satın almakla birleştirin.
iyi inşa ettik. Peki bu, inşa etme veya satın alma kararını vermemiz için bizi nerede bırakıyor? Aslında neye ihtiyacımız olduğuna bakalım.

Artık hiçbir modern sistem tek bir giriş noktasına güvenemez. Müşteri beklentileri, çeşitli kanalların gerekli olduğunu belirler. Şahsen, telefonla doğrudan veya çağrı merkezi, e-posta, sosyal medya, SMS, web, mobil, tablet üzerinden - hem mobil özellikli hem de yerel
uygulamalar, tümü içerik veya bağlam kaybı olmadan değiştirilebilir olma ihtiyacıyla. Şubede/mağazada ya da bizzat işe başlayan ancak randevu için yola çıkması gereken bir müşteri, o gün internet üzerinden giriş yaptığında kaldığı yerden devam edebilmek istiyor. Veya
Çevrimiçi olmaya başladıklarında hayal kırıklığına uğrarlar ve yardım için ararlarsa, sürece en baştan başlamak zorunda kalmak istemezler. Bu iç paydaşlar için de geçerlidir. Bir kuruluş içindeki bilgi zincirinin, müşterinin karşı karşıya olduğu kadar esnek olması gerekir.
seçenekleri. 

Peki veri girişleri herhangi bir yere başlamamız için sırada ne var? İlk etapta bu verilere ihtiyacımız olmasının bir nedeni var. İster yeni bir müşteri kuruluşla çalışmak istesin, ister mevcut bir müşteri yeni bir ürün veya hizmet istesin, hatta sadece günlük sorgular, şikayetler olsun.
veya bilgi talepleri. Tüm bunlar, talebi olabildiğince verimli ve kolay bir şekilde tamamlamak için tanımlanmış ancak esnek süreçlere başlamalıdır. Süreç genel olarak tanımlanır ve genellikle personel, önceden belirlenmiş olanlarla tamamlamak için bir dizi görevi takip etmek üzere eğitilir.
belirli veri girişlerine dayalı eylemler. 

Ne son müşteriler ne de sistem kullanıcıları, zaten bir yerde yakalanmışsa bilgileri herhangi bir yerde yeniden anahtarlamak zorunda kalmamalıdır. Aslında, kuruluş içinde herhangi bir yerde veya veri sağlayıcılar, kredi büroları gibi 3. taraf kaynaklardan bilgi mevcutsa,
tarama sağlayıcıları vb. ihtiyaç duyan tüm kullanıcılar için süreç boyunca erişilebilir olmalıdır. Süreç tanımlanmıştır ancak temas noktaları baştan sona değiştirilebilir olmalı ve toplanan veriler mümkün olduğunda entegre edilmeli ve izin verildiğinde yapılandırılmalıdır.
Açılır menüler, arama değerleri, tarih alanları ve kontrollü serbest metin değerleri kadar veri kalitesinin önceden yakalanmasını sağlamak için. Bu, süreç boyunca çok daha fazla otomasyona ve daha az istisna işlemeye olanak tanır.

Artık veriler aktif olarak yakalanma veya güncellenme sürecinde olduğuna göre, yapay zeka uygulanabilir. Personelin tüm ayrıntıları bilmesine gerek yoktur ve sistem politika kodlu kurallar kullandığından daha yeni üyeler bile daha karmaşık vakalar üzerinde çalışabilir.
personelin önceden kapsamlı eğitim ve deneyime sahip olması gereken kararları otomatik olarak alma mantığı. Gerektiğinde manuel müdahale için gözetim ve hatta kalite kontrol kontrollerine veya doğrudan istisna kuyruklarına izin verirken daha fazla hata yok.

Bütün bunlar sistematik bir yaklaşım gerektirir. Müşteri portföyü için bir personel çekmecesinde duran bir manilla klasörü fikrinin modası geçmiş ve gereksiz bir risk yaratıyor. Tek başına işlenen istemciler hem sınırlayıcı hem de gereksiz olabilir
aynı zamanda. Kurumsal bir müşterinin birden çok başka müşteride oturan yöneticileri varsa, neden her bir inceleme daha büyük resmi görmezden gelsin? Aynı yönetmeni her ilişkide birden çok kez gözden geçirecek misiniz yoksa yapabilir misiniz?
bir kez yapıp bu bilgileri kuruluş genelinde yeniden mi kullanacaksınız?

Faydanın görünür olması için ortak ilişkili taraflara sahip olmaları bile gerekmez. Benzer endüstriler, benzer müşteri müşterileri, ya müşteriniz satıcılarınız/tedarikçileriniz aynı zamanda müşteriyse? Bu, bizi bilgileri nasıl işlemeniz gerektiğine getirir.
ve kuruluşların bugünlerde yazılımları düşünürken neden kuruluş çapında bakmaları gerektiği. Bir sorunu tek başına görür ve ona göre davranır, bütçeler oluşturur ve her bir CRM, Fincrime, Client Outreach bileşeni için RFP'ler yayınlarsanız, sonunda
her şeyi bir araya getirmeye çalışırken, başlangıçta umut edilen herhangi bir potansiyel tasarruftan daha fazla kaynak harcamak. Şimdi bunu, ayrı bütçeler ve gözetim alabilecek her bölge veya iş kolu için uygulayın ve sonunda 8 versiyon elde edeceksiniz.
elde edebilecekleri ölçek ekonomilerini ortadan kaldıran alan başına yoğun özelleştirme nedeniyle kendisiyle entegre edilmesi gereken aynı yazılımın.

Bir çekmecede bulunan, yıllık veya başka bir şekilde gözden geçirilmesi gereken ve personelin ne yapması ve ne zaman yapması gerektiği konusunda eğitilmesi gereken bir klasör. İncelemenin tamamı (veya yeni katılım/ek ürün/hizmet/vb.) bileşik parçalara bölünebilir.
başka kişiler/ekipler tarafından yönetilemez. Sistem daha sonra bir görevin ne zaman tamamlandığını veya bir sonraki kişiye girişi için gönderilmek üzere yeterli verinin ne zaman yakalandığını belirleyebilir. Bütün bunlar vakalar ve kendi içinde alt vakalar olarak yapılandırılmıştır. Bu şekilde her elemanı
vakanın kendi son tarihi, yükseltme yolu, atanan ve onaylayanları olabilir. Bir personelin nasıl tamamlanacağını ve içindeki çeşitli unsurlar için kime gideceğini bilecek kadar deneyimli olması gereken tek bir büyük görev yerine, sistem artık işi atar
ve karar vericilerin neyin önemli olduğuna odaklanmalarını sağlamak için mümkün olduğunca çok otomatikleştirilmiş görevle tüm şirket genelinde zamanında tamamlanmasını sağlar.

Bunların hepsi iş açısından iyi ve iyi. Yapılan iş ve yapılması gerekenler bellidir. Ancak yazılımı kendimiz satın alıp almamamız veya oluşturmamız gerektiğine karar vermeye çalışırken, bu durum bazı şeyleri nasıl etkiler? Pekala, birden fazla kaynak olduğunu varsayalım
birden fazla sistemdeki verilerin Herhangi bir modern sistemin API güdümlü olması ve düşük kodlu/kodsuz yeteneklere sahip olması beklenir. Daha hızlı ve esnek yazılım için makul bir varsayım. Bugünlerde her şeyin, kaçınılması gereken bir tür mikro hizmet olarak ele alınması gerekiyor.
eski tarz yazılım monolitleri. Yazılım kurulmalı ve kullanılmalıdır, çünkü mevcut olanın en iyisidir ve gerektiğinde değişime uyum sağlamak için geleceğe hazırdır. Çok fazla teklif yerleşiktir ve yalnızca çok zor ve zaman alıcı oldukları için sürdürülür
değiştirmek. Bunun çoğu, kuralların sabit kodlanmış olması, muhtemelen verilerin kendisiyle iç içe geçmiş olması, verilerin yalnızca entegre edilmesi değil, aynı zamanda bilgi zincirindeki her ayrı yazılım parçası için birden çok kez çoğaltılması ve tek bir parçayı değiştirmeye çalışırsanız,
tüm sistem bozulabilir. Çok fazla eski düşünce süreci, eğer bozulmamışsa düzeltmeyin. Gerçekten ihtiyaç duyulan şey, tüm bu bileşen parçalarının mikro hizmetler olması, ihtiyaç duyulan verileri alması, otomatik kurallar veya kullanıcı girdileri/incelemeleri uygulaması ve
bir sonraki mikro hizmete iletir. Veriler birden fazla yerde saklanmamalıdır. Federe olabilir, ancak yedeklerin dışında çoğaltılamaz. CRM, Onboarding, KYC, Client Outreach, vb. sistemleriniz yalnızca ihtiyaç duydukları verilere erişmeli, değil
Bir tane seçmediyseniz, veri havuzlarının kendileri olun. Aynı verileri birden fazla konumda ve onu yöneten kurallarda çoğaltmak boşuna bir egzersizdir çünkü eklenen her ekstra sistem, ilgili karmaşıklıkları çoğaltır.

Bu bizi son değerlendirmeye getiriyor. Tek bir gerçek kaynağınız/Altın Kopyanız veya bunları güncelleyebilecek birden fazla gereksiz ve rekabet halindeki kayıtlarınız ve sistemleriniz olsun, yine de kendinizi, aşağıdakilere dayalı olarak başka bir gereksinim katmanında bulacaksınız:
iş, yetki alanı, müşteri türleri ve ürünler/hizmetler. Bir bireye bir şirket veya tröstten farklı davranılır ve gereksinimler ve uygunluk açısından tüketici/perakende, ticari veya kurumsal iş alanlarına göre farklılık gösterir. Örneklerin en temelinde, eğer
10 çeşit müşterimiz var (bireysel – bekar, evli vs, özel şirket, kamu şirketi, vakıf, hayır kurumu vs) ve 10 bölgede faaliyet gösterebilirsiniz ve 10 çeşit ürün/hizmet sunabilirsiniz, biz zaten buradayız olabilecek potansiyel olarak 1000'den fazla kural
uygulanacak. Bir bölge, bir iş kolu, bir müşteri tipi ve ürün veya hizmet için kurallar tanımlayıp bunun yerine gereksinimleri sistemin çözmesine izin vermek çok daha kolay olmaz mıydı? Yinelenenleri kaldırma ve daha önce kullanılan veri noktalarını yeniden kullanma
tedarik edilen. Bu, sürecinizi ve kurallarınızı veri katmanınızdan soyutlamanın yararıdır. 

Artık yazılım satın alma veya oluşturma konusundaki eski soruyu düşündüğümüzde, çok kanallı orkestrasyona, mümkün olduğunda süreç otomasyonuna, esnek kural mantığına, gözetim ve denetlenebilirlik için vaka yönetimine, düşük kod ve API odaklı, bir özete ihtiyacımız olduğunu biliyoruz.
veri katmanı ve farklı mantık katmanlarından miras alabilen akıllı bir kural motoru. Teknoloji pazarı, akla gelebilecek her niş sorunu memnuniyetle karşılayan yenilikçilerle dolu, ancak hangi noktada "raftan" almak mantıklı gelmiyor?
kendi başınıza oluşturmak yerine hepsinin özelleştirilmesi ve birbiriyle entegre edilmesi gereken ürünler. Düşük kodlu platformlar, gereksinimlerinizin %80'ine sahip olmanıza izin verebilir ve bu deltayı yalnızca %20 yapılandırmanız gerekir. Her iki dünyanın da en iyisi düşük
Başkalarının da kendisi için yeniden kullanılabilir bileşenler oluşturduğu kod platformu, böylece personeliniz veya sertifikalı 3. taraflar için özel gereksinimlerin geri kalanını oluşturma olanağına sahip olurken, işletmeniz için hızlandırıcılar olarak "hazır" ürünleri edinebilirsiniz.
kuruluşunuz için. Satın almak mı yoksa inşa etmek mi? Gerçekten ikisi de olmalı.