Şirketinizde kullanmadan önce bir yazılımı nasıl değerlendirirsiniz?

Bir şirkette yeni bir yazılımı benimsemek, önemli verimlilik kazanımları ile maliyetlere, iç dirence ve asla sonuçlanmayan sonsuz projelere takılıp kalmak arasında fark yaratabilir. Çoğu kuruluş, titiz bir değerlendirme sürecinden geçmeden "en yeni aracı" veya başka bir satıcının önerdiği her şeyi kullanma fırsatına atlar.

Yazılımı uygulamaya geçirmeden önce doğru şekilde değerlendirmek, sadece tabloda özellikleri karşılaştırmakla ilgili değildir; gerçek sorunları, süreçleri, insanları, toplam maliyetleri ve orta ve uzun vadeli riskleri anlamakla ilgilidir. Bunu metodik bir şekilde yaparsanız, yazılım dijital dönüşümünüz için stratejik bir kaldıraç haline gelir; aksi takdirde, yıllarca süren bir masraf olarak kalır.

İşletmelerde yazılım değerlendirmesinin önemi

Çoğu kurumsal çözüm (ERP, CRM , İK vb.) uzun yıllar boyunca kullanılır ve finans, satış, lojistik, insan kaynakları yönetimi veya müşteri hizmetleri gibi kritik süreçlerin temelini oluşturur. Bu, çok yüksek bir toplam sahip olma maliyeti (TCO) anlamına gelir, ancak akıllıca seçildiğinde yatırım getirisinde (ROI) de muazzam bir potansiyel sunar.

Yazılım pazarı, kalite, odak noktası ve olgunluk açısından oldukça dengesiz ve geniş bir pazardır; her satıcı genellikle farklı segmentlere ve kullanım durumlarına yönelik çeşitli ürünler sunar. Buna, değişen ihtiyaçları, çeşitli departmanların çıkarlarını ve zaman veya bütçe kısıtlamalarını da eklediğinizde, aceleci kararlar için mükemmel bir zemin oluşur.

Yanlış bir seçim sadece ilk yılda fark edilmez ; bir şirketi on yıl boyunca engelleyebilir: katı süreçler, dağınık veriler, maliyetli değişiklikler ve Excel veya diğer paralel araçlara geri dönen hayal kırıklığına uğramış ekipler. Bu nedenle, kapsamlı bir değerlendirmeye haftalar veya aylar ayırmak, herhangi bir dijitalleşme projesindeki en karlı yatırımlardan biridir.

Buradaki kilit nokta, yapılandırılmış bir süreci (açık adımlar, dokümantasyon ve objektif kriterlerle) kullanıcıların günlük ihtiyaçlarına dair pratik bir anlayışla birleştirmektir. Sadece 10 yıllık stratejik bir vizyona odaklanmak yeterli değildir, aynı şekilde sadece en çok sesini duyuran departmanın acil ihtiyaçlarını karşılamak da yeterli değildir.

Yazılımı değerlendirmek için doğru ekibi oluşturun.

Yazılım değerlendirmesi tek bir kişinin yapabileceği bir iş değildir, ne de sadece BT departmanı veya yönetim tarafından karar verilebilecek bir şeydir. İdeal olarak, sistemi kullanacak kilit alanları ve bakımını ve entegrasyonunu üstlenecek kişileri temsil eden çok disiplinli bir proje ekibi oluşturulmalıdır.

Bu seçim komitesinde farklı departmanlardan kilit kullanıcılar, BT personeli ve mümkünse arabuluculuk yeteneğine sahip tarafsız bir kişi bulunmalıdır : bu kişi üst düzey bir sponsor veya belirli tedarikçilerle hiçbir bağı olmayan harici bir danışman olabilir. Rolleri, çıkarları dengelemek ve kararın kişisel tercihlerden veya "her zaman böyle yapıldı" düşüncesinden etkilenmesini önlemektir.

Ekip üyelerinin organizasyonu iyice anlamaları , sağlam bir muhakeme yeteneğine sahip olmaları ve projeye ayıracak gerekli zamana sahip olmaları çok önemlidir. Sık yapılan bir hata, iyi niyetli ancak süreçler veya teknoloji konusunda az deneyime sahip veya zaten iş yükü fazla olan ve kestirme yollara başvuran kişileri işe almaktır.

Bu ekip, tüm süreçten sorumlu olacak : stratejinin tanımlanması, gereksinimlerin toplanmasının koordinasyonu, teklif talebinin (varsa) geliştirilmesi ve değerlendirilmesi, demoların düzenlenmesi, referansların doğrulanması, yatırım getirisinin (ROI) hesaplanması ve sözleşme görüşmelerine katılım. Erken aşamada dahil olmaları, başarı şansını büyük ölçüde artırır.

Proje hedeflerini, stratejisini ve kapsamını tanımlayın.

Kataloglara bakmadan veya demo talep etmeden önce , temel bir soruyu dürüstçe yanıtlamanız gerekiyor: Hangi sorunu çözmek istiyoruz ve başarılı olduğumuzu nasıl anlayacağız? Bu netlik olmadan, herhangi bir araç iyi... veya kötü görünebilir.

Proje ekibi, hem teknik hem de işle ilgili belirli hedefler üzerinde anlaşmalıdır . Örneğin, muhasebe kapanış süresini kısaltmak, faturalama hatalarını azaltmak, dağınık verileri merkezileştirmek, envanter izlenebilirliğini iyileştirmek veya İK süreçlerinden çalışan memnuniyetini artırmak gibi.

Hedeflere ek olarak, bir seçim stratejisi de oluşturulmalıdır : hangi zaman ufku dikkate alınacak, ne derecede standardizasyon hedeflenecek, yazılıma uyum sağlamak için iç süreçlerde ne kadar değişiklik payı olacak ve şirketin rekabet avantajını oluşturduğu için hangi kısımlar vazgeçilmez olacak; ve ayrıca, projenin yönetimini kolaylaştıracak proje yönetimi özelliklerine de danışılmalıdır.

Ayrıca yaklaşık bir zaman çizelgesi ve bütçe belirlemenin de zamanı geldi : analiz aşamasına, ön seçime, kavram kanıtına ve müzakereye ne kadar zaman ayrılacak? Ve işletmenin üstlenmeye istekli olduğu toplam yatırım aralığı (lisanslar, uygulama, eğitim, bakım).

Yazılım seçiminde karşılaşılan yaygın zorlukları belirleyin.

Hemen hemen tüm işe alım projeleri, daha sonra karşılaşılmaması için baştan itibaren dikkate alınması gereken bir dizi engeli paylaşır . Bu engelleri önceden tahmin etmek, daha gerçekçi bir süreç tasarlamaya yardımcı olur.

En sık karşılaşılan zorluklardan biri maliyetleri anlamaktır . Lisans veya abonelik fiyatı (ve yazılım lisans yöneticileriyle yönetim ) buzdağının sadece görünen kısmıdır: uygulama hizmetleri, özelleştirmeler, entegrasyonlar, veri geçişi, başlangıç ​​eğitimi, bakım, olası genişlemeler ve ekip zamanının iç maliyetini de hesaba katmanız gerekir.

Bir diğer engel ise yanlış seviyeye odaklanmaktır : yalnızca belirsiz, çok uzun vadeli stratejik bir vizyona veya tam tersine, yalnızca mevcut sorunları çözmeye odaklanmak. Bu bakış açılarının hiçbiri tek başına, aracın büyüme planlarına ve mevcut gerçeklere ne kadar uygun olduğunu doğru bir şekilde değerlendirmeye olanak sağlamaz.

Departmanlar arasındaki gerilimler de yaygındır . Her alan kendi önceliklerini savunur, bazı proje yöneticileri yerleşik tedarikçilere öncelik verebilir ve eski sistemler veya düzenli entegratörler mevcut durumu korumak için lobi yapabilir. Tüm bunlar, şeffaf bir şekilde yönetilmediği takdirde kararı etkileyebilir.

İhtiyaçları analiz edin ve yazılım gereksinimlerini tanımlayın.

Kritik bir aşama, ihtiyaç analizi aşamasıdır ; bu aşamada hangi süreçlerin desteklenmesi gerektiği, mevcut sorunların neler olduğu ve yeni sistemden ne beklendiği belirlenir. Bu çalışma, sonsuz kontrol listeleri oluşturmakla ilgili değil, işletmenin nasıl işlediğini anlamakla ilgilidir.

İşlem hacimleri, operasyonel karmaşıklık, sektör veya ülkeye özgü özellikler ve açık bir rekabet avantajı sağlayan faaliyetler vurgulanarak süreçlerin kapsamlı bir şekilde açıklanması tavsiye edilir . Çeşitli sağlayıcılar, bu farklılaştırıcı faktörler sayesinde kendilerini gerçekten ayırt edeceklerdir.

Bu aşamada, mevcut sistemde nelerin iyi çalıştığını (kaybetmemek için) ve nelerin kapsamadığını veya yetersiz kapsadığını not etmek de faydalıdır. Yapılan her türlü özelleştirme, yeni yazılımın pahalı geliştirmelerle değil, standart işlevsellik veya hafif uyarlamalarla ele alması gereken eksiklikler hakkında altın değerinde bilgi sağlar.

Tüm bu bilgileri düzenlemek için, teknik mimari, veri kaynakları, yönetim, güvenlik, kullanıcı deneyimi (UX), raporlama, analitik, entegrasyonlar, maliyetler ve destek gibi alanları içeren bir gereksinim matrisi oluşturulabilir . Her gereksinim, temel veya arzu edilen olarak sınıflandırılabilir ve önemine göre ağırlıklandırılabilir.

Gereksinimlerin belgelenmesi ve önceliklendirilmesi için en iyi uygulamalar

Genel gereksinim kontrol listeleri çok uzun zamandır var, ancak neredeyse tüm tedarikçiler temel maddelere "evet" işareti koyduğu için çözümler arasında farklılık yaratmaya nadiren yardımcı oluyorlar. Bu nedenle, bu kontrol listelerini şirketinizin özel koşullarını yansıtacak şekilde özelleştirmek önemlidir.

Gereksinimlerin toplanmasında tüm paydaşların dahil edilmesi çok önemlidir : eğer bir alan dışarıda bırakılırsa, daha sonra ihtiyaçlarını karşılamak için ayrı çözümlere ihtiyaç duyulması ve sistem ortamının daha da parçalanması çok muhtemeldir. İdeal olarak, çözüm, uygulama aşamalı olsa bile, tüm kuruluşu kapsamalıdır.

Önceliklendirme, küresel bir bakış açısıyla da yapılmalıdır . Her departmanın kendi ihtiyaçlarına öncelik vermesi yaygındır, ancak bu öncelikler genellikle kurumsal stratejiyle örtüşmez. Proje ekibi bu listeleri uyumlu hale getirmeli ve şirketin bakış açısından neyin hayati, önemli veya sadece arzu edilir olduğuna karar vermelidir.

Bir diğer zorlu nokta ise halihazırda var olan ile "vaat edilen " arasında ayrım yapmaktır. Birçok üretici, gelecekteki sürümlerde gelecek özelliklerden bahseder. Bunları akılda tutmak iyidir, ancak olgunlaşana ve diğer müşteriler tarafından üretimde kullanılana kadar kritik süreçleri kapsayacaklarına güvenmemelisiniz.

Yatırım getirisini (ROI) ve toplam sahip olma maliyetini (TCO) hesaplayın.

Hemen hemen tüm büyük yazılım projeleri, onay ve finansman sağlamak için yatırım getirisi (ROI) analizi gerektirir. Bunu doğru yapmak, başlangıç ​​maliyetinin ötesine bakmayı ve hem doğrudan tasarrufları hem de dolaylı faydaları nicelleştirmeyi gerektirir.

Yatırım getirisinin (ROI) hesaplanmasında, lisans veya aboneliklere, uygulama hizmetlerine, donanıma (varsa), eğitime, desteğe, güncellemelere ve olası genişletmelere yapılan yatırımın , eski sistemle veya manuel süreçlerle çalışmanın mevcut maliyetleriyle karşılaştırılması gerekir.

Faydaları zaman tasarrufunun çok ötesine uzanıyor : daha iyi veri kalitesi, daha az hata, daha iyi müşteri hizmeti, daha gelişmiş analitik yetenekler, mevzuata uyumsuzluk riskinin azalması ve çalışan memnuniyetinin artması gibi birçok avantaj sağlıyor. Her şey en ince ayrıntısına kadar ölçülemese de, bunları tahmin etmeye çalışmakta fayda var.

Uzun vadeli maliyet senaryolarını analiz etmek de tavsiye edilir : bazı SaaS sağlayıcıları çok cazip fiyatlarla başlar ve ardından fiyatları agresif bir şekilde artırır; diğerleri ise bakım kapsamına dahil olan hizmetleri sınırlar veya her büyük yükseltmede çok az yardım sunar, bu da birkaç yılda bir maliyetli yükseltme projelerine yol açar.

Teklif talebi ve tedarikçi ön seçimi

Gereksinimler net bir şekilde tanımlandıktan sonra , orta ve büyük ölçekli projelerde yaygın bir uygulama, sınırlı sayıda tedarikçiye teklif talebi (RFP) göndermektir. Amaç, tüm pazara sormak değil, bir düzine veya daha az sayıda uygun adayı seçmektir.

İhale şartnamesi, tedarikçilerle şirketin tanımını, temel süreçlerini, mevcut sistemde nelerin işe yaradığını ve nelerin yaramadığını ve önceliklendirilmiş bir gereksinim listesini paylaşır. Buradan hareketle, ihtiyaçları nasıl karşılayacaklarını, hangi ürünü önerdiklerini, sektördeki deneyimlerini ve uygulama planlarını detaylandıran bir teklif sunmaları istenir.

Bu ilk kısa listeye ulaşmak için çeşitli kaynaklar bir araya getirilir : uzmanlaşmış medyada yer alan başarı öyküleri, derneklerden gelen tavsiyeler, sektördeki meslektaşlardan alınan referanslar, yazılım dizinleri ve bazı durumlarda, belirli üreticilerle ticari bağı olmayan danışmanlık firmalarından alınan bağımsız tavsiyeler.

Önemli müşteriler veya işletme grubu tarafından önerilen tedarikçileri dahil etmek mümkündür , ancak bunlar her zaman diğer herkesle aynı değerlendirme kriterlerine tabi tutulmalıdır. Stratejik bir ortağın bir aracı kullanması, o aracın sizin bağlamınıza uygun olacağının garantisi değildir.

Değerlendirme sürecinin ilk aşaması: tarama ve puanlama

Teklif çağrısına verilen yanıtlar alındıktan sonra , daha detaylı bir değerlendirmenin ilk turu başlar. Amaç, uygun olmayanları elemek ve daha sonra daha kapsamlı bir değerlendirmeye tabi tutulacak küçük bir finalist grubu seçmektir.

Süreci düzenli tutmak için, temel kriterlerin değerlendirildiği bir puanlama tablosu tasarlamak çok faydalıdır : işlevsel uygunluk, teknolojik uygunluk, sektördeki deneyim, fiyatlandırma modeli, destek vb. Her kriterin bir ağırlığı olabilir ve her değerlendirici tanımlanmış ölçekte bir puan atar.

Tedarikçilerden birçok konuda açıklama istemeniz gerekeceğinden, yorum ve sorulara yer bırakmanız tavsiye edilir . Bazı sorunlar yazılı olarak çözülebilirken, diğerleri demo turu ve görüşmeler sırasında daha ayrıntılı olarak ele alınabilir.

Ağırlıklı puanlar toplandığında , genellikle önce güçlü tekliflerden oluşan bir grup, ardından orta seviyedeki teklifler ve son olarak da açıkça uygun olmayan teklifler ortaya çıkar. İdeal olarak, son kısa liste, ekibi bunaltmadan derinlemesine değerlendirme yapılmasına olanak sağlamak için üç ila beş adaydan oluşmalıdır.

Ön aşamada adil muamele ve objektif kriterler

Bu erken aşamada, tüm tedarikçiler için eşit şartlar sağlamak önemlidir . Sadece bazı tedarikçilerden özel ziyaretler veya yerinde gösterimler kabul etmek, algıları bozabilir ve ayrıcalıklı muamele şüphesi yaratabilir.

İyi bir uygulama, projenin tüm isteklilere sunulduğu ve soruların açıkça yanıtlandığı ortak bir oturum (yüz yüze veya çevrimiçi) düzenlemektir . Bu şekilde herkes aynı bilgiye sahip olur ve gizli avantajlar olmaz.

Teklifin bir iş belgesi olduğunu da hatırlamak önemlidir . İçindekilerin doğru olduğu varsayılsa da, olumlu yönleri vurgulamak ve riskleri en aza indirmek için yazılmıştır. İddiaların birçoğunun daha sonra gerçek dünya referansları ve pratik kanıtlarla doğrulanması gerekecektir.

Son olarak, aynı kriter için değerlendiriciler arasında puanlarda önemli farklılıklar olan yerleri gözden geçirmek faydalı olacaktır . Bu tutarsızlıklar genellikle birinin diğerlerinin fark etmediği bir şeyi fark ettiğini veya bir noktanın farklı şekilde yorumlandığını gösterir. Bu farklılıkları tartışmak, puanların ayarlanmasına ve nihai listenin iyileştirilmesine yol açabilir.

Detaylı değerlendirme ve derinlemesine karşılaştırma

Aday listesi tamamlandıktan sonra , sürecin en yoğun kısmı başlar: tedarikçilerin verdikleri sözleri doğrulamak, referans müşterilerle görüşmek, sözleşmeleri detaylı olarak incelemek ve sistemi gerçek vakalarda işlerken görmek.

Bu, adaylardan ön aşamada öğrendikleri doğrultusunda tekliflerini gözden geçirmelerini istemek için iyi bir zamandır : öncelik sıralamasında değişiklikler olmuş olabilir veya örneğin hizmet seviyeleri veya ürün geliştirme planları gibi daha net bir şekilde belirtilmesi gereken hususlar olabilir.

Diğer müşterilerden gelen referanslar paha biçilmezdir . İdeal olarak, benzer büyüklükteki, aynı veya karşılaştırılabilir sektördeki kuruluşlarla görüşmeli ve onlardan uygulama deneyimleri, gerçek faydalar ve "ama"lar hakkında bilgi almalısınız: karşılaştıkları sürprizler nelerdi, sıfırdan başlasalar neleri farklı yaparlardı?

Buna paralel olarak, entegrasyonlar, güvenlik ve mimari konularına daha derinlemesine bakmanın zamanı geldi : mevcut sistemlerle nasıl bağlantı kurulacak, veri geçişi için hangi seçenekler mevcut, koda dokunmadan ne kadar özelleştirme mümkün ve hangi yönetim ve izleme araçları sunuluyor.

Faydalı gösteriler nasıl düzenlenir (sadece pazarlama amaçlı değil)?

Ticari tanıtımlar genellikle etkileyici görünmek üzere tasarlanır , sistemin karmaşık senaryolarınız altında nasıl performans gösterdiğini göstermek için değil. Bu nedenle, ekibinizin ne görmek istediğiniz konusunda bir yol haritası belirlemesi hayati önem taşır.

İyi bir uygulama, satıcının demo sırasında izlemesi gereken süreçlerin ve senaryoların ayrıntılı bir metnini hazırlamaktır . Tüm adaylar aynı metni alır, böylece eşit şartlarda karşılaştırılabilirler ve ancak sonunda vurgulamak istedikleri önemli özellikleri sergilemeleri için zaman verilir.

Bu betik, işletmenizdeki hem standart süreçleri hem de yaygın istisnaları içermelidir : stokta olmayan ürünler için siparişler, set satışları, karmaşık onay iş akışları, özel mutabakatlar, bordro detayları, yerel düzenlemeler vb. Aracın gerçekten uygun olup olmadığını işte burada görebilirsiniz.

Mümkün olduğunca, demo için şirketinizin verilerini veya en azından gerçeğe yakın bir veri kümesini kullanmak idealdir. Bu, kullanıcıların sistemle ilgili günlük deneyimi görselleştirmelerine ve kurgusal verilerle fark edilmeyecek sorunları belirlemelerine yardımcı olur.

Gözünüzü kamaştıracak şeylerden kaçının ve yerinde verilen referanslardan yararlanın.

Genellikle sunum yapan kişi, oldukça karizmatik ve kusursuz bir sunuma sahip, son derece eğitimli bir profesyoneldir. Performansa kapılıp asıl noktayı, yani aracın kritik süreçleri nasıl ele aldığını ve uyarlamak için ne kadar çaba gerekeceğini gözden kaçırmak kolaydır.

Sunumların eleştirel bir bakış açısını teşvik etmesi ve rahatsız edici konular da dahil olmak üzere bolca soru sorulmasını sağlaması önemlidir : bilinen sınırlamalar, gerçekçi yol haritaları, geçmişteki başarısızlıklar, değişiklikler için ortaklara bağımlılık vb. Şimdi ne kadar çok soru yanıtlanırsa, daha sonra o kadar az sürpriz yaşanır.

Önemli müşterilerin tesislerine yapılan ziyaretler de bir diğer kritik an. Burada sadece sistemi çalışırken görmek değil, aynı zamanda bağlamı anlamak da önemli: şirket kültürü, ayrılan kaynaklar, talep düzeyi ve başarısının imkansız koşullar olmaksızın kendi kuruluşunuzda tekrarlanabilir olup olmadığı.

Ne görmek istediğiniz ve kimlerle konuşacağınız konusunda önceden anlaşmak önemlidir : son kullanıcılar, bölge yöneticileri, BT, yönetim… Her biri farklı bir bakış açısı sunacaktır. Ayrıca, uygulama sırasında en büyük zorluklar, gerçekçi zaman çizelgeleri ve günlük operasyonlar üzerindeki etki hakkında soru sormaya istekli olmalısınız.

Değişim yönetimi ve ekip katılımının rolü

Yazılım uygulama başarısızlığının ana nedenlerinden biri teknik değil, insani bir nedendir: değişime direnç ve benimseme eksikliği. İnsanlar bir aracın kendi görüşleri alınmadan "dayatıldığını" hissederlerse, bu direnç yaratacak ve kestirme yollar arayışına yol açacaktır.

Bu nedenle, sorunları belirleme, gereksinimleri tanımlama ve seçenekleri değerlendirme süreçlerine en başından itibaren ekibi dahil etmek çok önemlidir . Burada önemli olan her bireyin nihai kararı vermesi değil, neyin işe yaradığı ve neyin yaramadığı konusunda onların pratik bakış açılarını da dahil etmektir.

Kullanım kolaylığı da bir diğer önemli faktördür . Güçlü ancak hantal bir sistem, öğrenme eğrisi çok dik olduğu için yeterince kullanılmayabilir. Arayüz, gezinme mantığı ve süreç netliği yalnızca teknik uzmanlar tarafından değil, gerçek kullanıcılar tarafından da değerlendirilmelidir.

Son olarak, eğitim ve iç destek en başından planlanmalıdır: her alanda kim irtibat kişisi olacak, hangi oturumlar düzenlenecek, hangi materyaller mevcut olacak ve üretim kullanımının ilk aylarında sorular nasıl yanıtlanacak.

Kritik unsurlar: esneklik, ölçeklenebilirlik ve güvenlik

Bir yazılımın şirketle birlikte büyümesi için esnek ve ölçeklenebilir olması gerekir. Esneklik, sistemin yarısını yeniden yazmaya gerek kalmadan modüller ekleyebilmek, iş akışlarını uyarlayabilmek, özel alanlar tanımlayabilmek veya yeni araçlar entegre edebilmek anlamına gelir.

Ölçeklenebilirlik, performanstan ödün vermeden veya maliyetleri artırmadan daha fazla kullanıcıyı, daha büyük veri hacimlerini ve daha büyük organizasyonel karmaşıklığı desteklemekle ilgilidir . Birçok çözüm az sayıda kullanıcıyla iyi çalışır, ancak şirket büyüdükçe zorlanır.

Bilgilerin güvenliği ve gizliliği pazarlık konusu olamaz. Hangi protokollerin kullanıldığını (iletim sırasında SSL/TLS şifreleme, depolama sırasında şifreleme, oturum ve çerez yönetimi, güvenli API'ler, SQL enjeksiyon koruması vb.) ve sağlayıcının hangi güvenlik ve uyumluluk sertifikalarına sahip olduğunu; ayrıca telemetri ve veri gizliliğini nasıl yönettiklerini kontrol etmek tavsiye edilir.

Modern ortamlarda, bulut çözümleri, sağlayıcının sağlam bir altyapıya ve bulut yedeklemelerinin nasıl şifreleneceği ve senkronize edileceği de dahil olmak üzere net veri koruma politikalarına sahip olması koşuluyla, yedekleme, felaket kurtarma ve iş sürekliliği konularında önemli avantajlar sağlar.

Kullanılabilirlik, veri merkezileştirme ve analitik

Sezgisel bir arayüz, benimseme sürelerini kısaltır ve kılavuzlara ve uzun eğitimlere olan bağımlılığı azaltır. Bu, işlevsellikten ödün vermek anlamına gelmez, aksine kullanıcıların sonsuz menülerde kaybolmadan ihtiyaç duyduklarını bulabilmeleri için işlevselliği düzenlemek anlamına gelir.

Veri merkezileştirme, birden fazla departmanın iş birliği yapması ve bilgi paylaşması gereken şirketlerde bir diğer önemli gereksinimdir . İyi bir sistem, ilgili tüm bilgilerin tek bir depoda saklanmasına, uygun izinlerle erişilmesine ve tekrarlanmamasına olanak sağlamalıdır.

Rapor oluşturma ve veri analiz etme yeteneği artık isteğe bağlı değil. Yazılım, stratejik hedeflerle uyumlu ve ideal olarak gerçek zamanlı olarak net, ölçülebilir raporlar oluşturmaya olanak sağlamalıdır. Bu, operasyonel gösterge panellerinden yönetim gösterge panellerine kadar her şeyi içerir.

İnsan kaynakları alanında, İK Analitiği veya İnsan Kaynakları Analitiği gibi kavramlar, yetenek yönetiminin iş sonuçları üzerindeki etkisini anlamamızı sağlar. Bu yeteneklerin değerlendirmeye dahil edilmesi, İK'nın daha stratejik bir rol oynamasına yardımcı olur.

Maliyetler, lisanslama modeli ve "küçük yazılar"

Yazılımın görünen fiyatı nadiren tüm hikayeyi anlatır . Temel pakete nelerin dahil olduğunu ve nelerin ekstra ücrete tabi olduğunu (destek, bakım, güncellemeler, ek modüller, ek depolama alanı, entegrasyonlar vb.) tam olarak sormak çok önemlidir.

Teklifleri karşılaştırırken sadece ilk fiyatı değil, çözümün ömür boyu maliyetini de göz önünde bulundurmalısınız . Çok ucuz bir ürün, her küçük yükseltme veya alışkın olduğunuz özellikler için ödeme yapmanızı gerektirebilir ve bu da birkaç yıl sonra gerçek maliyeti önemli ölçüde artırabilir.

Dağıtım modeli de gözden geçirilmelidir : şirket içi çözümler daha fazla kontrol sağlar ancak kendi altyapılarını ve bakımlarını gerektirir; bulut/SaaS çözümleri genellikle daha esnektir, kendilerini günceller ve maliyetleri zaman içinde daha iyi dağıtır.

Önemli noktalardan biri, bakım veya abonelik ücretlerinin nasıl gelişeceğini , yıllık yükseltme limitlerinin olup olmadığını, kullanıcı eklerken ne olacağını, hizmetten ayrılmak istediğinizde ne olacağını ve büyük sürüm yükseltmelerinin nasıl yönetileceğini anlamaktır.

Entegrasyonlar, geliştirme platformu ve uygulama türü

Pratikte, neredeyse hiçbir şirket sadece tek bir sistem kullanmaz . Birkaç sistem çalıştırmak normaldir: ERP, CRM, gider yönetimi çözümleri, İK, analitik araçlar vb. Bu nedenle, yeni yazılımın mevcut sistemlerle iyi entegre olması hayati önem taşır.

Hangi standart bağlantı noktalarının mevcut olduğunu , üreticinin hangi API'leri sunduğunu, çift yönlü entegrasyonlara izin verip vermediğini ve entegrasyonların her güncellemede bozulmaması için değişikliklerin nasıl yönetildiğini kontrol etmekte fayda var ; ayrıca istemci ortamlarında yazılım kurulumunu otomatikleştirmek için hangi seçeneklerin mevcut olduğunu da incelemek gerekir.

Temel geliştirme platformu da önemlidir . Ne kadar özelleştirilebilir ve açık kaynaklı olursa (her zaman özel geliştirmeye dayanmadan), güncellemeleri kaçırmadan sistemi şirketin özel ihtiyaçlarına uyarlamak o kadar kolay olur.

Uygulama süreci ayrıntılı olarak ele alınmalıdır : aşamalar, son tarihler, metodoloji (çevik, şelale, hibrit), hataların nasıl yönetileceği, hangi testlerin yapılacağı, hangi ortamların olacağı (geliştirme, test, üretim) ve tedarikçinin bu adımlarda ne gibi taahhütlerde bulunması gerektiği.

Destek, müşteri hizmetleri ve kavram kanıtı

Birçok proje, ürünün kendisinden değil , satıcı veya uygulama ortağından alınan destek ve rehberliğin kalitesinden dolayı başarısız olur. Bu nedenle, sunulan destek kanallarını, çalışma saatlerini, hizmet seviyesi anlaşmasını (SLA) ve bakım sözleşmesine nelerin dahil olduğunu anlamak çok önemlidir.

Ekibin kendi verileri ve süreçleriyle sınırlı bir süre çalışabileceği bir test ortamı (ücretsiz deneme, sanal ortam veya kontrollü pilot uygulama) oluşturulması şiddetle tavsiye edilir . Bu test, hipotezleri doğrulamaya ve taahhütte bulunmadan önce gerekli ayarlamaları belirlemeye yardımcı olacaktır; bazı durumlarda, gerçek dünya ortamını simüle eden sanal ağlar kullanılarak test yapılması önerilir .

Ürünün karmaşıklığına bağlı olarak , tam bir konsept kanıtı yalnızca finalistlerden biriyle mümkün olabilir; diğer durumlarda iki veya üçü test edilebilir. Önemli olan, ilgili tüm departmanların bulgularını belgelemeleri ve istikrarı ve performansı değerlendirmek için uygulama test araçlarını kullanmalarıdır.

Bu sonuçlar, kullanıcı deneyimi, işlevsel uyumluluk, maliyetler ve algılanan riskleri birleştiren son yapılandırılmış değerlendirmeye katkıda bulunacak ve nihai karar ve sözleşme müzakerelerinin yolunu açacaktır.

Sözleşme müzakeresi ve uzun vadeli planlama

Kapsamlı bir değerlendirmeden sonra, genellikle gereksinimleri karşılayan iki veya üç seçenek bulunur . Buradan sonra, şirketin geleceğini tehlikeye atmamak için nihai seçim ve sözleşme görüşmeleri çok önemli hale gelir.

Bu aşamada müzakere gücü genellikle müşteride olsa da , tedarikçiyi alt edilmesi gereken bir rakip olarak değil, uzun vadeli bir ortak olarak görmek tavsiye edilir. Dengeli bir anlaşma, her iki tarafın da başarılı bir uygulama sağlaması için teşvikler sunar.

Sözleşmede ilgili tüm hususlar ayrıntılı olarak belirtilmelidir : lisanslar veya abonelikler, varsa donanım, uygulama kapsamı, pilot maliyetler, başlangıç ​​ve devam eden eğitim, destek seviyeleri, veri geçişi, entegrasyonlar, güvenlik, özelleştirmeler ve gelecekteki sürümlerin yönetimi.

Ayrıca , tüm belirsizlikler giderilene kadar "kesin bir kazanan" ilan etmeden alternatif seçenekleri açık tutmak da akıllıca olur . Bu aşamada (gizli maliyetler, kısıtlamalar, kabul edilemez maddeler) sürprizlerle karşılaşmak ve seçimin yeniden değerlendirilmesini gerektirmek oldukça yaygındır.

Bu sürecin sonunda şirket, yalnızca mevcut ve gelecekteki ihtiyaçlarına uygun yazılımı seçmekle kalmayacak, aynı zamanda teknoloji projelerini değerlendirme, seçme ve yönetme konusunda paha biçilmez iç deneyim kazanmış olacak; bu da rekabetçi kalabilmek için giderek daha kritik hale gelecektir.

Yeni bir sistemi benimsemek, bir uygulama yüklemekten çok daha fazlasını içerir : süreçleri yeniden düşünmek, alanları koordine etmek, beklentileri yönetmek ve insanları farklı şekilde çalışmaya hazırlamakla ilgilidir. Yöntem, gerçekçilik ve katılım yaklaşımıyla ele alındığında, yazılım "zorunlu bir gider" olmaktan çıkıp şirkette sürekli iyileştirmenin gerçek bir motoru haline gelir.