"Görünmez" bir şeyi, soyut bir şeyi satmak, sıradan bir ürünü (örneğin giyim veya inşaat malzemeleri) satmaktan çok daha zordur. Hizmet pazarlamasının ayrı bir alan olarak tanımlanması ve özel bir rol verilmesi tesadüf değildir. Bugün maddi olmayan üretim alanının özellikleri ve hizmetlerin nasıl satılacağı hakkında konuşacağız.
Hizmet nedir
Hizmet, tedarik sürecinde üretilen ve çoğu durumda gayri maddi olan, yani alıcının herhangi bir maddi varlığa sahip olmadığı her türlü faaliyet, fayda veya mal anlamına gelir. Bununla birlikte, bazı hizmetler maddi açıdan doğrudan mallara bağlıdır. Yani, bir uçak bileti alırken, tam olarak A noktasından B noktasına hareket eden bir hizmet satın almış oluyoruz.
Satış Özellikleri
İstisnasız tüm hizmetlerin, hizmetlerin nasıl satılacağı hakkında konuşurken dikkate alınması gereken ortak özellikleri vardır.
Soyutluk
En mantıklı nokta. Hizmetler soyuttur; yani dokunulamaz, görülemez veya tadılamaz. Kuaföre geldiğimizde önceden yeni bir saç kesimi “denemiyoruz”. Tedarikçi açısından bakıldığında bu ne anlama geliyor? Satışları artırmak için hizmetleri daha somut hale getirmeniz ve müşterinin elde edeceği temel faydaları vurgulamanız gerekir. Örneğin, bir kuaför için bu, en iyi çalışmalarının fotoğraflarını içeren ve becerisini doğrulayan bir portföy olabilir.
Kaynaktan ayrılamazlık
Diğer bir özelliği ise hizmetin her zaman bir kişi veya ekipmanla yakından ilişkili olmasıdır. Bu nedenle konsere bilet alırken sevdiğimiz müzisyenleri görmeyi bekleriz. Herhangi bir nedenle grup üyelerinden birinin değiştirilmesi gerekirse, hizmet artık aynı olmayacaktır. Bu, doğrudan hizmet sağlama sürecini uygun şekilde organize etme ihtiyacını ima eder: aynı anda çok sayıda müşteriyle çalışmayı öğrenin veya hizmet sürecini hızlandırın.
Kalite tutarsızlığı
Hizmetlerin doğru şekilde nasıl satılacağından bahsederken, hizmet kalitesinin lokasyona, teslimat zamanına ve diğer yüzlerce faktöre bağlı olarak sürekli değiştiğini hatırlamak önemlidir. Aynı garson bir gün size iyi hizmet ederken, başka bir gün yemeğinizi düşürebilir veya kaba davranabilir (örneğin, kendini iyi hissetmediği için). Bu ne anlama gelir? Hizmet sektöründe bir işe başlarken, gerçekten iyi uzmanları çekmek ve eğitmek için her zaman yeterli bir bütçe ayırmak gerekir. Ayrıca herhangi bir şikayeti hızlı bir şekilde işleme koymak ve çalışanların çalışmalarını iyileştirmek için müşterilerle geri bildirim oluşturmak gerekir.
Depolamanın imkansızlığı
Bu bir işletme sahibi için neden önemlidir? Gerçek şu ki, hizmet sektörünün hemen hemen tüm sektörlerinde talep dalgalanıyor: sahil beldelerine yapılan turlar çoğunlukla yaz aylarında, şehirdeki taksiler ise iş gününün en yoğun olduğu saatlerde rezerve ediliyor. Bu durumda hizmetler nasıl satılır? Talebi istikrara kavuşturmaya ve giderleri daha etkili bir şekilde planlamaya yardımcı olan çeşitli pazarlama stratejileri vardır:
- Fiyatların zamana göre farklılaşması. Talebin bir kısmını yoğun dönemlerden yavaş zamanlara kaydırmak için birçok şirket indirimlerden yararlanıyor; örneğin sinemalar akşamın erken saatlerindeki gösterimler için biletleri düşük fiyatlarla satıyor.
- Talebin yoğun olduğu saatlerde bekleyenler için alternatif yaratmak. İyi bir seçenek, restoranda masa bekleyenler için ayrı bir kokteyl barıdır.
- Ön sipariş sisteminin tanıtılması.
Diğer seçenekler de uygulanıyor. Bazı şirketler, talebin maksimum olduğu dönemlerde geçici çalışanları veya yarı zamanlı çalışanları çekiyor.
Hizmetlerin pazarlanması: genel şema
Hizmetlerin nasıl etkili bir şekilde satılacağını tek tek açıklamak oldukça zordur, çünkü her şey belirli bir şirketin özelliklerine ve faaliyet gösterdiği nişin özelliklerine bağlıdır. Moskova'nın yerleşim bölgesinde büyük bir havayolu şirketi ve küçük bir kuaför için evrensel bir tarif sunmak mümkün değil. Ancak tüm hizmet sektörü işletmelerinde ortak olan belirli bir algoritma halen mevcuttur.
Adım #1: Pazar Araştırması
İlk aşama, faaliyet göstermeyi planladığınız pazarın kapsamlı ve kapsamlı bir çalışmasıdır. Analiz iki yönde gerçekleştirilir:
- rakipler;
- potansiyel müşteriler.
Rakipler hakkında bilgi toplamak, tam olarak ne sunduklarını, müşterileri neyin çektiğini, onlarla nasıl etkileşime girdiklerini ve hangi fiyatları belirlediklerini anlamak için gerçekleştirilir. Pazarın kilit oyuncularının kimler olduğunu ve sizinle aynı hedef kitleyle aynı bölgede faaliyet gösterenleri bilmek önemlidir. Bu, bir şirketin pazarlama stratejisini önemli ölçüde etkileyebilir.
Analiz için masa başı ve saha yöntemleri kullanılmaktadır. Masa üstü verilerinin kaynakları arasında sektör dergileri ve rehberleri, veritabanları ve yayınlanmış derecelendirmeler yer alır.
Bununla birlikte, yayınların çoğu ulusal veya bölgesel düzeyde çalıştığından, belirli bir bölge için gerekli bilgileri elde etmek çoğu zaman imkansızdır. Daha sonra doğrudan saha araştırmasına geçin:
- potansiyel bir müşteri kisvesi altında rakipleri aramak;
- ticari tekliflerin, reklam ürünlerinin talep edilmesi ve incelenmesi;
- Reklam faaliyetlerinin analizi.
Ayrıca diğer şirketlerin müşterileri hakkında mümkün olduğunca fazla bilgi edinmek de gereklidir. Ana araçlar anketler, anketler (internette ve sokaklarda), röportajlardır. Benzersiz bir teklif geliştirmek için, şu anda başvurdukları şirketlerin tam olarak neyi beğendiklerini/beğenmediklerini öğrenmek önemlidir.
Adım No. 2: Fiyatlandırma politikasının ve ek hizmetlerin geliştirilmesi
Öncelikle satılan hizmetlerin maliyetini doğru hesaplamak gerekiyor. Bu göstergeyi bildiğinizde, başabaşa çıkmak için kaç müşteriyi çekmeniz gerektiği ve para kazanmak için hangi işaretlemeyi ayarlamanız gerektiği konusunda size rehberlik edilecektir. Nasıl yapılır?
Bir hizmetin maliyeti, yüklenicinin bu hizmetin sağlanması sırasında yaptığı tüm masrafların toplamını içerir. Maliyetler 2 büyük gruba ayrılır:
- Kalıcı. Bunlar, bina kiralamayı, faturaların ödenmesini, yönetim giderlerini, ekipmanın (bilgisayarlar, ofis ekipmanı) amortismanını içerir.
- Değişkenler. Çalışanların maaşları, malzeme alımı vb.
Temel olarak giderler hesaplanırken, belirli bir hizmetin sağlanması için gereken süre temel alınır (örneğin, programcının siparişi tamamlamak için toplam sürenin kaç saatini harcadığı).
Günümüzde küçük, orta ve büyük işletmeler er ya da geç iş süreçlerini otomatikleştirmek için neyi seçeceklerini merak ediyor: bulutu mu yoksa kutuyu mu?
Bazıları yazılımın artık basit, sıradan bir hizmet olarak giderek daha popüler hale geldiğini öne sürerken, diğerleri hâlâ aynı yazılımı satın almanın en kolay yollarından birinin yalnızca kutulu sürümler olduğuna inanıyor.
Ancak bulutun mu yoksa kutunun mu daha iyi olduğunu anlamak için bu çözümlerin yeteneklerine daha yakından bakmayı öneriyoruz.
Hizmet olarak yazılım.
Yani bulut hizmetleri bir veri işleme teknolojisidir. Bu durumda, kullanıcıya bir web tarayıcısı aracılığıyla hizmet olarak yazılım (SaaS), iOS, Android veya Windows Phone işletim sistemlerini temel alan mobil cihazlara yönelik uygulamalar sağlanır. Bulut altyapısının tamamı kullanıcıdan gizli olduğundan, bu teknolojiyi kullanmak ve yönetmek için özel beceri veya bilgiye sahip olmasına gerek yoktur. Ayrıca bulut hizmetleri, CRM sistemlerini “demokratikleştirdiği” için küçük ve orta ölçekli şirketler arasında popülerdir.
Bulut CRM sistemlerinin avantajları:
- teorik olarak bulut sistemlerinde disk alanı, RAM ve işlemci sayısı miktarı kesinlikle sınırsızdır;
- kullanıcıların yazılımı yüklemek ve yapılandırmak için zaman harcamasına gerek kalmayacak; bulut hizmetlerine erişmek için bir web tarayıcısı veya akıllı telefon yeterli olacak;
- pahalı ekipman satın almaya gerek yok;
- belirli görevleri yerine getirmek için çalışanların zamanından ve çabasından (ve bazen ekipmanın kapladığı yerden) önemli ölçüde tasarruf sağlar;
- ödeme yalnızca kullanılan bilgi işlem gücü ve gerçekleştirilen işlemler için yapılır;
- şirketin altyapıyı kurmak için para ayırmasına gerek yok;
- neredeyse tüm kullanıcılar web tarayıcılarını ve bir hizmet sınıfı olarak İnternet hizmetlerini nasıl kullanacaklarını bildiklerinden, eğitimle zaman kaybetmeye gerek yoktur;
- Bulut sistemleri çoğunlukla yüksek vasıflı profesyoneller tarafından sürdürülür ve bu da yazılım hizmetinin kalitesi üzerinde çok olumlu bir etkiye sahiptir.
Bulut CRM sistemlerinin dezavantajları:
- güvenlikle ilgili sürekli ortaya çıkan sorular nedeniyle, tüm verilerin üçüncü taraf bir sağlayıcıya emanet edilemeyeceği ortaya çıkıyor (bu arada, bu yalnızca depolama için değil, aynı zamanda bazı verilerin işlenmesi için de geçerli);
- örneğin veri kaybı olasılığı: servis sağlayıcıdaki teknik bir arıza nedeniyle;
- işletmenin iş süreçlerini dikkate alarak ek işlevleri "vidalayamamak";
- Çoğu bulut hizmetinin net standartlardan yoksun olması nedeniyle, bir bulut hizmet sağlayıcısından diğerine geçmeye karar veren kullanıcılar oldukça ciddi sorunlarla karşılaşabiliyor. Ek olarak, sağlayıcı kendi bulut hizmetlerini güncellemek isterse, örneğin arayüzü güncellemek isterse, abonelerin de bunu kullanacağını açıklığa kavuşturmaya değer mi, çünkü kimse onlara sormayacak;
- İnternet erişimi gereklidir. Elbette, bir yandan bu oldukça uygundur, ancak diğer yandan bazen İnternet birkaç saatten birkaç güne kadar "kaybolur".
Kutulu çözüm.
Kutulu bir yazılım ürününe gelince, bu, onlar için standart bir dizi işleve sahip, belirsiz sayıda alıcıya yönelik olan bir yazılımdır. Yani, bu durumda, temel çözüm kavramı, hem işlevsellik hem de tedarikçi tarafından sistemde daha fazla değişiklik yapılması olasılığı açısından belirli bir sınırlama anlamına gelir. Şöyle ki: yazılım başlangıçta bitmiş bir ürün olarak satılmaktadır ve bu nedenle belirli bir şirketin bireysel iş görevleriyle hiçbir bağlantısı yoktur!
Kutulu CRM sistemlerinin avantajları.
- oldukça hızlı çünkü alıcı, lisansları satın alma gününde alıyor;
- gerekli formları doldurup yanıt bekleyerek zaman kaybetmenize gerek yok;
- lisanslı yazılım satan mağazalardan satın alınabilir;
- yalnızca 1 bilgisayar için lisans satın almanız gerekiyorsa faydalıdır;
- Kutulu ürün, ürün içerisinde yer alan talimatlara göre kullanıldığı için kullanıcının ipuçları her zaman elinin altında olacaktır;
- Güncelleme hizmeti ve teknik destek sayesinde kullanıcılar (herhangi bir soru veya sorun çıkması durumunda) “bire bir” vb. sistemle baş başa kalmayacaklardır.
Kutulu CRM sistemlerinin dezavantajları.
- sistemi kendi başınıza kurabilmeniz için oldukça yüksek düzeyde bilgi birikimine sahip olmanız gerekir;
- diğer yazılım ürünleriyle sık sık yaşanan çatışmalar;
- kutulu versiyonun her zaman beyan edilen işlevselliği kullanması nedeniyle, ürünün maliyetini etkileyecek şekilde en azından biraz tasarruf sağlamak için hiçbir şekilde değiştirilemez veya azaltılamaz;
- Temel olarak bu sürüm, kutu lisansının geçerlilik süresi boyunca diğer bilgisayarlar için ek lisans satın alma olanağı sağlamamaktadır.
SAAS'ın ve temel çözümün temel özellikleri.
Elbette bir yandan kutulu çözüm, basitliği ve uygulanması için gereken kısa süre, düşük fiyatı ve kalite garantisi (tabii ki ürün saygın üreticilerden satın alınmışsa) nedeniyle caziptir.
Yani kutulu bir çözüm seçerken, tabiri caizse sahip olduklarınızdan memnun olarak mağazaya gelip seçmeniz ve kurmanız yeterli. Sonuçta, kutulu sürüm kural olarak standart işlevsellik sağlar. Ve gelecekte açık kaynaklı bir ürün olsa bile, geliştirilebilir, ancak öncelikle şirketin ihtiyaçlarını özellikle CRM sisteminin yeteneklerine göre ayarlaması gerekecek, bunun tersi mümkün değil! Bu nedenle kutulu versiyon, örneğin iş süreçlerinin benzersizliğine ulaşmış ve çok sayıda çalışana sahip olan, satış departmanını şirketin diğer tüm departmanlarıyla birleştirecek şirketler için uygun olmayacaktır. .
Ancak şirketler genellikle bu seçeneğin en ucuz ve en hızlı seçeneklerden biri olduğuna inanarak bir CRM sisteminde çalışmak için bir kutunun yeterli olduğuna karar verirler. Ancak iş süreçlerini tam olarak otomatikleştirmek için ürünü çok dikkatli seçmek, beyan edilen işlevselliği incelemek vb. gerektiğini unutmamalıyız. Çünkü bu konuya gereken özeni göstermezseniz, şu gerçekle karşılaşabilirsiniz: Müşteri veri tabanı ve satış kontrolü ile çalışmak için bile kutulu versiyonun yeterli olmayabileceğini!
Yazılım (SaaS) müşteriye hizmet olarak sunulduğu için satın alınmasına gerek yoktur. Bunun yerine, kullanıcı yalnızca bir abonelik ücreti ödeyerek onu kiralar. Bu, şirketin klasik, standart yazılım lisanslama planının aksine, yazılımın ve dağıtımı için bir donanım platformunun satın alınmasına büyük miktarlarda para yatırmamasına olanak tanır. Destek ve sistem güncellemeleri ise satıcı tarafından ücretsiz olarak sağlanmaktadır. Ayrıca SaaS çözümleri herkesin yalnızca gerçekten ihtiyaç duyduğu ve kullandığı yazılım işlevleri için ödeme yapmasına olanak tanır. Ayrıca bir gün müşteri programın herhangi bir ek fonksiyonuna ihtiyaç duyduğunu fark ederse veya tam tersine belirli program modüllerine artık ihtiyaç duymadığı gerçeğiyle karşı karşıya kalırsa bu sorun kolay ve hızlı bir şekilde çözülebilir.
Ayrıca SAAS çözümleri, neredeyse tüm iş süreçlerinin, muhasebe ve işbirliği yönetiminin otomatikleştirilmesi için muazzam işlevsellik sunar.
Ancak en büyük bulut sağlayıcılarında bile önemli donanım arızaları yaşanıyor. Bu nedenle, dünya pratiğinde kullanıcıların uygulamalara uzun süre erişemediği birçok durum zaten mevcuttur. Evet ve aynı sağlayıcının hatası nedeniyle "İnternetin kapatılması" uzun zamandır alışılmadık bir durum değil, ancak böyle bir sıkıntı "bulut" kaynaklarıyla çalışmayı kesinlikle imkansız hale getiriyor.
Ancak, kutulu veya bulut çözüm lehine son seçimi yapmadan önce, bunların tüm artılarını ve eksilerini değerlendirmeniz, tüm riskleri tartmanız ve şirketin iş hedeflerine ve hedeflerine en uygun çözümü tam olarak seçmeniz gerekir.
Kullanıcılarımıza “Proje yönetim sisteminin kutulu versiyonuna ihtiyacımız var mı?” konulu bir anket gerçekleştirdik. Bizim için bu sorunun kesin cevabı büyük önem taşıyor. Yeni işlevler için sistem geliştirme yolunu ve önceliklerini belirler.
Ankete bulut sürümünü kullanan 155 şirket ya da sadece sistemi tanımak için kaydolan şirketler katıldı. Her biri üç cevap seçeneğine sahip yalnızca üç soru vardı.
Kesimin altında sonuçları ve çıkarımlarımızı içeren grafikler bulunmaktadır.
Örnek
Örneklem çok büyük değil (155 katılımcı), kullanıcılar mektup almaktan pek hoşlanmıyor, bir şeye oy vermek şöyle dursun. Katılımın tek motivasyonu sonuçların yayınlanacağına dair sözdü.Her soru için yanıt verenlerin sayısı, yanıt seçeneklerinin sayısından 50 kat daha fazlaydı. Cevapların dağılımındaki rastgele hata büyük olmayacak -
yüzde birkaçı ve cevapların dağılımına bağlıdır.
Deneydeki önemli yanlışlıklar arasında örnekleme olasılığı yer alıyor - yalnızca oy vermek isteyenler ve genel örneklemden rastgele kullanıcılar değil. Ve tabii ki numunenin kendisi; veri tabanımız küçük işletmelere yöneliktir.
Tüm bu faktörler dikkate alınmalı ve anket sonuçlarına göre sonuçlar çıkarılabilir.
Soru No.1
Proje yönetimi için kutulu bir çözüme mi ihtiyacınız var yoksa bulut çözümü de uygun mu?
Katılımcıların %32'si temelde yalnızca paket çözümlerle çalışmaya hazır iletişim ve görevlerle çalışmak için. Yanıt verenlerimiz arasında küçük işletmelere karşı bir önyargı olduğunu düşünürsek, SaaS'ı hiç dikkate almayan minimum pazar payı %32'dir.
Birkaç yıl önce bu durum mevcut değildi. O zamanlar başka bir b2b projesi üzerinde çalışıyorduk, ancak kutuya yönelik talepler ara sıra oluyordu ve ciddiye alınmıyordu. Artık kutulu versiyonu piyasaya sürerek en popüler ticari talebi kapattık.
Soru 2
Paket çözüme duyulan ihtiyacın temel nedeni nedir?
Evde güvenlik ve veri depolamada güçlü önyargı- %60'tan fazla. Ve bu küçük işletmeler için! Büyük şirketlerle doğrudan iletişim kurduğunuzda güvenlik ve paket çözüm her zaman ilk veya ikinci sorudur. (şu soruyla yarışıyor: "Ekibin ne yaptığına ilişkin rapor nasıl alınır")
Soru 3
Son 3 yılda kutulu çözümler daha alakalı hale geldi mi? Yarovaya yasasının herhangi bir etkisi var mı?
Yarovaya Yasası'nın kendisi kimseyi fazla endişelendirmiyor. Güvenliği bu kadar yükseğe yerleştiren belirli bir şey yoktur. Bu her zaman birçok faktörün birleşimidir ve kullanıcılar bu faktörlerdeki değişiklikleri gerçekten takip etmezler. Bir müşteriyle aramızdaki tipik bir diyalog şuna benzer:
Paketlenmiş bir çözüme ihtiyacımız var.
- Neden tam olarak kutulu olanı? bulutla başlayalım, daha hızlı başlayacak
- Hayır, artık yönetim yalnızca sunucularımızda kurulu olması durumunda kabul edecektir.
- Hala ücretsiz bulut tabanlı Trello'yu kullandığınızdan bu yana neler değişti?
- Evet ve bu bize uymuyor. Pek bir şey değişmedi ama artık politika yalnızca güvenli çözümlere geçmek.
Anketten ve şirketlerle iletişimden elde edilen sonuçlar:
- Firmaların en az %30'u sadece kutularla çalışmaya hazır.
- Parasal açıdan bakıldığında bu, bizim durumumuzda pazarın en az %70'idir. Tahmin, çalışanların şirket büyüklüğüne göre dağılımına dayanmaktadır.
- Geçtiğimiz birkaç yılda güvenlik tercihlerinde dramatik değişiklikler yaşandı. Bu eğilim daha da yoğunlaşacak. Dağıtım modelleri silo kurulumuna benzer olacaktır.
- Buluttan kendi kendine barındırılana aktif bir geçiş eğilimi var. Bunu ancak b2b'de görebiliriz. Bulut sistemlerden tamamlanan görevleri kutumuza yükleme fonksiyonu bizden isteniyor.
- Kutulu sürümü bir nedenden dolayı yayınladık. Yönün geliştirilmesi gerekiyor. Bulut birçok kişi tarafından yalnızca bir test fırsatı olarak algılanıyor.
Not: Anket: Rusya'da Çevik 2017
YouGile olarak biz, Rusya'daki esnek metodoloji hakkında geniş bir araştırma yürütüyoruz. Burada yukarıdaki ankete göre kat kat daha fazla yanıtlayana ihtiyacımız var. Şu ana kadar 100'den biraz fazla kişi katıldı. Sorunun en popüler yanıtı: “Şirketinizde Agile kullanılıyor mu?”"Evet, ama oldukça fazla" - ankete katılanların %54,5'i.
Katılın - “Rusya'da Çevik 2017” anketine katılın
12 soru, yaklaşık 3 dakika
Herhangi bir aktiviteyi otomatikleştirmenin iki yolu vardır: uygun bir paketlenmiş ürün seçin veya bir yazılım ürününün (PP) geliştirilmesini sipariş edin. Her yaklaşımın artılarına ve eksilerine ve yazılım seçerken ortaya çıkan yaygın hatalara bakalım. Göz önünde bulundurulan yaklaşımlar, yalnızca belge akışı ve ofis işlerinin değil, her türlü faaliyetin otomatikleştirilmesi için tipiktir.
Günümüzde okul öncesi eğitim kurumlarının veya vaka yönetimi hizmetlerinin birçok yöneticisi, kuruluşlarındaki ofis süreçlerini veya belge akışını otomatikleştirmek için yazılım seçme sorunuyla karşı karşıyadır. Kural olarak, EDMS seçimi, kuruluşun çalışanları arasındaki deneyim alışverişiyle başlar ve bazı çalışanların daha önce ilgilendiği EDMS'nin çalışmalarının işlevleri ve özellikleri hakkındaki bilgilere dayanır. Ancak bir kuruluşa uygun olan bir EDMS'nin, başka işlevlere veya organizasyon yapısına sahip bir kuruluş için her zaman ideal olmayabileceğini unutmamanız gerekir. Herhangi bir aktiviteyi otomatikleştirmenin iki yolu vardır: uygun bir paketlenmiş ürün seçin veya bir yazılım ürününün (PP) geliştirilmesini sipariş edin. Her yaklaşımın artılarına ve eksilerine ve yazılım seçerken ortaya çıkan yaygın hatalara bakalım. Göz önünde bulundurulan yaklaşımların, yalnızca belge akışı ve ofis işleri için değil, her türlü faaliyetin otomatikleştirilmesi için tipik olduğunu belirtmek isterim.
E.S. Ulanova, Proje Direktörü, Yeni Teknolojiler Merkezi "Parus" CJSC
Bir yazılım ürününün yanlış seçiminin sonuçları birçok kişi tarafından bilinmektedir - uygulama ve daha fazla çalışma sırasında iş süreçlerinde sürekli kesintiler, artan fonksiyonel sorumluluklar nedeniyle departmanlar arasındaki çatışmalar ve yeni sorumlulukların düzenli bir şekilde dağıtılmaması. Bu yazıda, farklı yazılımların özelliklerini ve uygulama kapsamını dikkate alarak belirli bir durumda neyin seçilmeye değer olduğunu bulmaya çalışacağız.
Kutulu PP seçimi
Kutulu yazılım ürünü Belirsiz sayıda alıcıya yönelik olan ve tüm alıcılar için standart işlevlerle "olduğu gibi" sağlanan bir yazılımdır.
Kutulu ürünler genellikle imalat şirketi tarafından herhangi bir kullanıcının kullanabileceği eksiksiz bir kurulum ve kurulum talimatları seti ile oluşturulup dağıtılır.
Paketlenmiş bir ürünün en tipik örneği, kişisel bilgisayarlar için Microsoft Windows işletim sistemidir.
Kurulumun özel bilgi ve beceri gerektirdiği daha karmaşık tipte kutulu çözümler vardır - bunlar bu makalenin konusu olan ürünlerdir. Böyle bir kutulu çözümün temel özelliği, önceden bildirilen, değişikliğe tabi olmayan işlevselliktir ve sistemin kendisi, geliştirme şirketinin katılımı olmadan kutulu ürünün standart ayarları aracılığıyla kullanıcılara uyum sağlar.
Kutulu EDMS'ler kural olarak sınırlı sayıda iş veya işlev içeren bir lisansa sahiptir. İşlevselliği hafif olan ücretsiz bir sürüme sahip kutulu EDMS'ler vardır.
Bu versiyonlar, bu ürünü tadilat veya değişiklik yapmadan kullanabilen küçük ticari şirketler için uygun olabilir.
Ayrıca özgür yazılımla (OS)* ilgili temel olarak başka kutulu EDMS platformları da vardır. Bu tür EDMS platformları, bağımsız geliştirme ve müşteri organizasyonunun gereksinimlerine uyarlama için tasarlanmıştır.
EDMS platformu, belge onayına yönelik iş süreçleri, belgelerin elektronik versiyonlarının saklanması ilkeleri, elektronik belgelerle işbirliği ve diğerleri gibi EDMS'nin temel ilkelerini uygulayan paketlenmiş bir üründür. EDMS platformu, EDMS için belirlenen gereksinimlere ve görevlere bağlı olarak küçük ayarlamalar veya büyük değişiklikler gerektirebilir.
Kutulu EDMS'nin dağıtımı (Şekil 1), doğrudan geliştiriciden müşteriye veya bir aracı (EDMS'nin kurulmasına ve yapılandırılmasına yardımcı olacak bir EDMS satıcısı) aracılığıyla gerçekleşebilir. Dağıtım yöntemi, müşterinin kadrosunda nitelikli BT uzmanlarının bulunmasına bağlıdır. Bu nedenle, şirketin böyle bir uzmanı tutması mümkün veya gerekli değilse, bir bayiyi işe almak mantıklı olacaktır.
Pirinç. 1. Kutulu EDMS dağıtım şeması
Kutulu yazılım geliştirme şirketi- Tüm bağlantı talimatlarıyla birlikte tamamen kullanıma hazır bir ürün üreten firma.
Kutulu yazılım satıcısı geliştirme şirketi ile paket yazılımın tüketicisi arasında, paket yazılımın kurulumu ve işlevselliğinin sürdürülmesine yönelik hizmetler sağlayan bir aracıdır. Bayi ayrı bir şirket olabileceği gibi bir şirketin paket yazılım geliştiren bir bölümü de olabilir.
Paket yazılımın organizasyon-müşterisi- bağımsız olarak (BT destek hizmeti aracılığıyla) paketlenmiş bir ürünü yapılandırabilen ve onunla çalışabilen veya paket yazılım satıcısının hizmetlerini kullanabilen bir yazılım tüketici organizasyonu.
Kutulu EDMS'nin artıları ve eksileri
Kutulu EDMS birçok Rus üretici tarafından üretilmektedir. Ve bu tür çözümlerin bariz artıları ve eksileri var. Paket yazılımın temel avantajı, özel geliştirmeye kıyasla satın alma maliyetlerinin azalmasıdır. Ana dezavantaj, sistemin işlevselliğini değiştirememektir.
Kutulu bir ürünün doğru seçimiyle, satın alma işleminden elde edilen fayda, yazılımı değiştirme fırsatlarının eksikliğinden önemli ölçüde daha ağır basar.
Paket yazılım satın almanın diğer bir avantajı, satın alınan ürünün teslim alınmasının nispeten kısa sürede gerçekleşmesi ve bu tür ürünlerin kurulum kolaylığı genellikle EDMS çözümleri arasındaki rekabet faktörlerinden biri olduğundan, piyasaya sürülmesinin minimum maliyetidir.
Kullanıcılar için birleşik bir teknik destek hizmetinin varlığı, geliştirme şirketinin paketlenmiş ürünlerin bakım maliyetlerinin ana unsuru olarak adlandırılabilir. Üstelik sistem ne kadar karmaşıksa onu desteklemek için o kadar fazla kaynak gerekir. Alıcılar için böyle bir teknik destek organizasyonu başka bir avantajdır, çünkü teknik desteği sürdürmenin maliyeti bu kutulu çözümün tüm alıcıları arasında paylaştırılır ve yeterli sayıda kullanıcıyla, alıcının bütçesi için neredeyse farkedilemez olabilir. Ancak bu yaklaşımın dezavantajını anlamaya değer - paket yazılım geliştiricisi, ürününü hangi yönde geliştireceğine ve onu geliştirip geliştirmeyeceğine, bu ürün için teknik destek hizmeti sürdürmenin mantıklı olup olmadığına veya buna değip değmeyeceğine kendisi karar verir. desteğini ve gelişimini durduruyor. Kutulu bir çözüm satın alınması durumunda, yazılımın daha da geliştirilmesinin yönü geliştiricinin kendisi tarafından belirlenir ve yaklaşımları her zaman bu kutulu yazılımı satın alan müşterilerin görevleriyle örtüşmez. Bir geliştirici için en büyük kâr genellikle kutulu bir çözümün ilk satışından gelir; daha fazla destek, müşteriler için bir bonus seçeneği ve bunları diğer ürün ve çözümlerine bağlama fırsatıdır.
Ne yazık ki bazen ticari şirketler belirli bir ürün için güncelleme yayınlamayı durdurur. Bunun nedeni, şirketin yeni bir yön geliştirmeye ilgi duyması ve eski ürünü desteklemenin kârsız bir faaliyet haline gelmesi olabilir.
Paketlenmiş EDMS'nin geliştiricisi, bu EDMS'yi veya EDMS'nin bu sürümünü (sorun giderme dahil) desteklemeye devam edeceğine dair herhangi bir garanti vermez. Bu durumda, kutulu ürünün kullanıcısının bir seçeneği vardır: bu ürünü iyileştirme yapmadan (ve Rusya mevzuatının desteği olmadan) kullanmak veya başka bir ürünle değiştirmek.
Kutulu PCB seçerken yapılan hatalar
Kutulu bir EDMS seçerken yapılan ana hata, bilgi araştırması ve kuruluşun ihtiyaçlarının analizi aşamasının eksikliğidir. Birçok yönetici, geliştirici sunumlarına ve gösterilen EDMS'nin bir veya diğer işlevselliğinin yüzeysel bir karşılaştırmasına dayalı olarak paketlenmiş yazılım satın almayı tercih eder. Aynı zamanda herkes, sunumda geliştiricinin sistemdeki en iyiyi göstereceğini ve elbette yazılımın tüm eksikliklerini gizlemeye çalışacağını anlıyor.
Bu tür incelemeler sırasında müşteri, yazılımın tüm işlevlerini her zaman tam olarak takdir edemez, mevcut tüm işlevlere olan ihtiyacın farkına varamaz ve bunların kendi kuruluşu için özel olarak ne kadar gerekli olduğunu anlayamaz, ayrıca bazen geliştiricinin standart işlev adları altında ve müşteri çeşitli süreçleri anlar. EDMS'de bir fonksiyonun mevcut olması, her zaman müşteriye uygun bir biçimde var olduğu anlamına gelmemektedir.
Seçmenin başka bir yolu daha var - paketlenmiş bir ürünü sınırlı sayıda iş istasyonunda kısa bir süre için test etmek. Bu yöntem sunumlardan daha iyi sonuçlar verebilir ancak önceki yaklaşımın neredeyse tüm dezavantajları kalacaktır.
Geliştiriciler, müşterinin süreçlerini kendi sistemlerine uyarlamaya çalışıyor ve bunu "bu doğru" gerçeğinden "sistem ancak bunu yapabilir ve herkese yakışıyor" gerçeğine kadar çeşitli inançlarla gerekçelendiriyor. Elbette, bir kuruluşta ofis çalışmalarının nasıl yürütüleceğine ilişkin kurallar ve tavsiyeler vardır (GSDOU, GOST'ler ve OST'ler gibi), ancak bu sürecin belirli bir kuruluşta nasıl daha rahat organize edileceğine kuruluşun sorumlu çalışanları tarafından karar verilmelidir. .
Çoğu zaman yazılım ürünü satıcıları müşterinin iş süreçlerini anlayan uzmanlar değildir. Bu nedenle, paketlenmiş bir ürünün geliştiricisi, kazara veya profesyonelce, riski kendisine ait olmak üzere, müşterinin neye ihtiyacı olduğunu tahmin etmeyi umar. Bu gibi durumlarda yapılması mantıklıdır. Kuruluşun iş süreçlerine ilişkin bilgi araştırması, değerlendirilmesi ve gerekiyorsa ayarlanması, Müşterinin bilgi süreçlerini anlaması için değil, geliştiricinin kendisini kuruluşun sorunlarına ve görevlerine kaptırması için büyük ölçüde ihtiyaç duyulan şey.
Bununla birlikte, bilgi anketi ihtiyacını anlamak (geliştiricilerin müşteri süreçlerine dahil edilmesi), olgun iş süreçlerine sahip, yani süreçlerin geliştiği, kaydedildiği ve belirsizliğe neden olmayan kuruluşlar için tipiktir.
Tüm Rus şirketleri ve kuruluşları bu tür süreçlerle övünemez, bu nedenle çoğu Rus müşteri, bir EDMS seçme sürecini iş süreçlerinin optimizasyonu ile birleştirir ve öncelikle süreçlerini organizasyonel düzeyde kaydetmek ve birleştirmek için bir bilgi araştırması gerçekleştirir.
EDMS'yi uygulayan şirket liderlerinin varsayımlarından biri, kaosu otomatikleştirmenin imkansız olduğu, bu nedenle önce iş süreçlerini kaydetmenin ve ardından EDMS'nin işlevselliğine ilişkin gereksinimleri tanımlamanın gerekli olduğu ifadesi olmalıdır.
Aksi takdirde, EDMS uygulandıkça süreçlerde ayarlamalar yapılacak ve kullanıcılardan sürekli olumsuz tepkiler alınmasına, yani mevcut süreçlerin analiz edilmeden, farkında olmadan yok edilmesine yol açacaktır.
Bilgi araştırması sırasında süreçler “olduğu gibi” tanımlanmalı, açıklanan tüm süreçler analiz edilmeli ve gerekiyorsa tartışmalı konular düzenlenmeli ve kuruluş dokümanlarında belgelenmelidir. Bundan sonra hazırlıklı olmalısınız süreç otomasyonu konsepti. Mevcut tüm süreçlerin korunmasına ilişkin bir sonuç şeklinde ifade edilebilir veya kuruluşun çalışmasını optimize etme gereklilikleriyle sonuçlanabilir ve bu, bazen bir departmanın yeniden düzenlenmesiyle bile sonuçlanabilir.
Bir otomasyon konsepti oluştururken, bir EDMS'nin uygulanmasından ekonomik bir etki elde etmenin yolları tanımlanmalı ve analiz edilmelidir. Süreçlerin “olması gerektiği gibi” tanımlanmasının sonucu, EDMS'nin otomatikleştireceği işlevlere yönelik gereksinimler olmalıdır. Ancak bundan sonra kutulu bir ürün seçmeye devam edebilirsiniz.
Belirli bir ürünün seçimi, EDMS gereklilikleri ile yazılım ürünü geliştiricisinin bu tür işlevlerin kullanılabilirliği hakkındaki beyanının karşılaştırılmasına dayanmalıdır. Ana görev, kuruluşunuzun çalışma sistemini EDMS'deki mevcut işlevselliğe uyacak şekilde değiştirmek değil, yalnızca ihtiyaçlarınızı karşılayan ürünleri seçmektir.
Paketlenmiş ürünler arasında seçim yapmak oldukça zor olabilir çünkü bazen aynı süreci otomatikleştirmeye yönelik ürünler tamamen farklı şekillerde üretilebilir. Seçim söz konusu olduğunda önemli bir avantaj, paketlenmiş bir ürünü belirli bir şirketin organizasyon yapısına uyacak şekilde esnek bir şekilde özelleştirebilme yeteneğidir.
Özel yazılım
Özel yazılımın tanımı adından gelir; sipariş üzerine üretilen bir yazılım ürünüdür.
Özel yazılımın şüphesiz avantajı, benzer yapı ve işlevlere sahip başka bir kuruluşun imajı ve benzerliğinde değil, kuruluşun tüm özelliklerine uygun olarak müşterinin gereksinimlerine göre oluşturulmasıdır. Ancak böyle bir yazılım oluşturmanın maliyeti her zaman uygulamadan elde edilen sonucu haklı çıkarmaz.
Özel yazılım öncelikle bu işlevin spesifik olduğu otomasyon alanları için kullanışlıdır. Bazı kuruluşlarda belge akışı ve ofis işleri, kutulu çözümlerin otomasyondan beklenen sonucu veremeyeceği şekilde yapılandırılabilir (örneğin kolluk kuvvetleri, bankalar veya belirli bölgesel dağılım ve bağlılığa sahip ticari kuruluşlar). Bu tür organizasyonlar için doğru çözüm, özel yazılımların uygulanması olacaktır..
Bilgi araştırması aşaması, kutulu bir çözümün seçilmesi durumunda olduğu gibi,Özel yazılımın geliştirilmesinde en önemlisidir, çünkü bu aşamada geliştirici tarafında programcılar tarafından daha fazla tasarlanıp oluşturulacak işlevlerin gereksinimleri belirlenir.
Özel bir EDMS oluşturmanın çeşitli yolları ve yöntemleri vardır. En yaygın olanı iki geliştirme yaklaşımıdır:
çağlayan (klasik gelişim);
yinelemeli gelişme.
Pirinç. 2. EDMS geliştirmenin kademeli modeli
Cascade (Şekil 2) (İngilizce şelale modeli - “şelale modeli”), geliştirme sürecinin bir akış gibi göründüğü, gereksinim analizi, tasarım, uygulama, test etme, entegrasyon aşamalarından başarıyla geçtiği bir yazılım geliştirme süreci modelidir. ve destek. Bu metodolojiye dayanarak, örneğin otomatik sistemlerin (34. ve 19. seri) oluşturulmasına yönelik Rus standartları ve GOST'ler oluşturuldu.
GOST 34. seri:
GOST 34.601-90 “Bilgi teknolojisi. Otomatik sistemler için standartlar seti. Otomatik sistemler. Yaratılış aşamaları";
GOST 34.201-89 “Bilgi teknolojisi. Otomatik sistemler için standartlar seti. Otomatik sistemler oluştururken belgelerin türleri, eksiksizliği ve belirlenmesi";
GOST 34.602-89 "Otomatik bir sistemin oluşturulmasına ilişkin teknik özellikler";
GOST 34.603-92 “Bilgi teknolojisi. Otomatik sistemlerin test türleri";
GOST 34.320-96 “Bilgi teknolojileri. Veritabanı standartları sistemi. Kavramsal çerçeve ve bilgi tabanına yönelik kavramlar ve terminoloji";
GOST 34.321-96 “Bilgi teknolojileri. Veritabanı standartları sistemi. Veri Yönetimi Referans Modeli."
GOST 19. seri:
GOST 19.001-77 “Birleşik program dokümantasyon sistemi. Genel Hükümler";
GOST 19.101-77 “Birleşik program dokümantasyon sistemi. Program türleri ve program belgeleri";
GOST 19.102-77 “Gelişim aşamaları”;
GOST 19.103-77 “Programların ve program belgelerinin tanımları”;
GOST 19.104-78 “Temel yazıtlar”;
GOST 19.105-78 “Program belgeleri için genel gereklilikler”;
GOST 19.106-78 “Basılı program belgeleri için gereklilikler”;
GOST 19.201-78 “Teknik özellikler, içerik ve tasarım gereksinimleri”;
GOST 19.202-78 “Şartname. İçerik ve tasarım gereksinimleri” vb.
Yönergeler:
RD-34.698-90 “Metodolojik talimatlar. Bilgi Teknolojisi. Otomatik sistemler için bir dizi standart ve yönerge. Belge içeriği gereksinimleri için otomatik sistemler.”
Bu standartlar, öncelikle EDMS için tüm gereksinimlerin tanımlanması gerektiğini ve ancak bundan sonra kodlama aşamasına, yani belirli bir programlama dilinde belirli bir algoritmayı uygulamak için program kodu ve komut dosyaları yazma sürecine geçilebileceğini ima eder. Dahası, gereksinimler hem sistemin işlevsel görevlerini hem de diğer sistemlerle tüm etkileşim yöntemlerini, EDMS'de bilgi sunma yöntemlerini içermelidir, bu nedenle çoğu zaman tüm bu gereksinimlerin GOST'a göre tanımlanması uzun zaman alır (birkaç aydan itibaren) birkaç yıla kadar).
Bu geliştirme modeli aşağıdaki durumlarda iyidir:
● açıklanan gereksinimlerin güncelliğini yitirmesi için zaman olmadığından, birkaç haftadan 2-3 aya kadar süren projeler için uygulama yaparken;
● alt görevlerin olmadığı ve işlevsellik geliştirmenin birkaç aşamasının olmadığı sistemleri uygularken (örneğin, EDMS'nin ana işlevselliğini geliştirdikten sonra, muhasebe sistemi ile etkileşiminin sonuçlandırılması gerekecektir, ancak bu etkileşim için henüz bir gereklilik yoktur) ;
● oluşturulan EDMS'nin gereklilikleri açıkça tanımlandığında ve kaydedildiğinde.
Yinelemeli veya yinelemeli yaklaşım(Şekil 3) - elde edilen sonuçların sürekli analizine ve önceki çalışma aşamalarının ayarlanmasına paralel olarak işin yürütülmesi. Aynı zamanda, geliştirmenin her aşamasındaki geliştirme, yinelenen bir yineleme döngüsünden geçer: Planlama - Uygulama - Kontrol Etme - Değerlendirme.
Pirinç. 3. Yinelemeli yazılım geliştirme
Bu yaklaşım geliştirildiği ABD ve Batı'da yaygınlaştı. Rational Software'in Rational Unified Process (RUP) gibi dünyaca ünlü yazılım geliştirme metodolojileri de benzer bir yaklaşımı benimser.
Bu yaklaşımın temeli, fonksiyonelliğin ve gereksinimlerin giderek derinleştirilmesi ve oluşturulan fonksiyonelliğin müşteri ile birlikte sürekli analiz edilmesidir. Yinelemeli bir yaklaşımla, kullanıcılara göstermek ve sistem arayüzü ve uygulama süreçlerine yaklaşım hakkında geri bildirim almak için mümkün olan en erken zamanda bir EDMS prototipi geliştirilir.
Rusya pazarı için böyle bir yaklaşım, kullanıcıların yüksek kalitede eğitilmesini ve henüz tamamlanmamış EDMS'ye aşina olmalarını gerektirir, çünkü bu genellikle henüz oluşturulmamış sisteme karşı olumsuz bir tutuma neden olabilir. EDMS'nin geliştirilmesine bu tür kullanıcı katılımı hem artı hem de eksi olarak adlandırılabilir. Kullanıcılar bir yandan geliştirmenin nasıl yapıldığını görüyor ve süreci etkileyebiliyor, diğer yandan bu zaman ve gerçek kullanıcı katılımı gerektiriyor (ki bu onların ana faaliyeti değil).
Yinelemeli Yaklaşımın Faydaları
Sistemin işleyişi ile kuruluşun fiili faaliyetlerinin gereklilikleri arasındaki tutarsızlıkların erken tespiti;
Çabaların ağırlık noktası, EDS'nin en önemli ve kritik alanlarına (örneğin, belgelerin kaydedilmesi, kontrol altına alınması, ardından performans disiplinine ilişkin raporların geliştirilmesi vb.) yöneliktir;
Tüm projenin başarısını bir bütün olarak değerlendirmenize olanak tanıyan sürekli yinelemeli (yani tekrarlanan) testler;
İhtiyaçlarını gerçekten karşılayan bir ürün yaratmak için müşterinin kilit çalışanlarını EDMS geliştirme aşamasına dahil etmek;
Görevler ve işlevsellik açısından tek bir EDMS'nin modüler geliştirilmesi ve modüler uygulanması imkanı;
Projenin mevcut durumunun gerçekçi bir değerlendirmesi ve bunun sonucunda müşterilerin ve doğrudan katılımcıların projenin başarılı bir şekilde tamamlanmasına daha fazla güven duyması.
Ne seçeceksin?
Sonuç olarak: EDMS seçimi konusunda elbette evrensel bir tavsiye yok, ancak hem uygun EDMS tipini (paket ürün veya özel yazılım) belirlerken hem de seçerken birçok sorun ve hatadan kaçınmanıza yardımcı olacak yaklaşımlar var. Kutulu ürünler arasında kuruluşunuz için en uygun EDMS.
Öncelikle kurumun ihtiyaçlarını analiz etmeniz ve bunlara göre bir yazılım ürünü seçmeniz gerekiyor. Kutulu bir çözüm, EDMS işlevselliği açısından kuruluşun ihtiyaçlarını karşılamaya uygunsa, o zaman onunla devam etmek daha iyi (daha ucuz ve daha hızlı) olur, ancak o zaman bu ürünün geliştiricisine olan bağımlılığı hatırlamanız gerekir. Gereksinimleri analiz ettikten sonra kuruluş, özel geliştirme olmadan yapamayacağını anlarsa, tüm eylemlerin düzenlenmesi ve gerekli tüm proje belgelerinin oluşturulmasıyla geliştirme projesinin düzenlenmesine özel dikkat gösterilmelidir. Bu, özel yazılım geliştiren şirkete bağımlı kalmamanıza ve gerekirse EDMS'nin uygulanması ve çalıştırılmasının neredeyse her aşamasında sistemi sorunsuz bir şekilde değiştirmenize yardımcı olacaktır.
Uzman görüşü
D.V. Volodin, analist, Microsoft SharePoint yöneticisi, Elektronik Ofis Sistemleri şirketi
Birçok sözde Kutulu ürünler, sistemi büyük ölçüde belirli bir kuruluşun özelliklerine uyarlamanıza olanak tanıyan zengin bir ayar kümesine sahiptir.
Aynı zamanda, EDMS sınıfı sistemler uzun zamandan beri pazardaki nişini sağlam bir şekilde işgal etmiştir; sektöre özel olanlar da dahil olmak üzere birçok hazır çözüm bulunmaktadır. Ayrıca müşterinin olası özellikleri dikkate alındığında bile EDMS işlevselliğinin büyük çoğunluğu standart niteliktedir. Bu koşullar altında sıfırdan bir EDMS geliştirme girişimi, tekerleği yeniden icat etmek gibi düşünülebilir.
Şu anda EDMS pazarında kutulu ve özel ürünler arasındaki sınırları bulanıklaştırma yönünde oldukça açık bir eğilim var. Bu türler aktif olarak birbirleriyle yarı yolda buluşmaya çalışıyor: "kutular" çok sayıda ayarla büyümüş ve özel gelişmeler kopyalanıp hazır çözümler biçiminde piyasaya sürülüyor.
Müşterinin EDMS seçme konusundaki zorlu sürecini kolaylaştırmak için üç işlevsellik grubunu ayırmayı önerebiliriz:
değerlendirilen her ürün için yeni yetenekler:
Tipik konfigürasyon (minimum maliyet); gerekirse geliştiricinin talimatlarına göre müşterinin kendisi tarafından dağıtılabilir;
Değişiklik gerektirmeyen gelişmiş konfigürasyon (ortalama maliyet); uzmanların sistemin uygulanmasına katılımını gerektirir;
İşlevselliğin iyileştirilmesi, yeni modüllerin geliştirilmesi (maksimum maliyet); programcıların katılımını ve tam teşekküllü bir yazılım geliştirme projesini gerektirir.
Günümüzde mevcut çoğu EDMS geliştiricisi bu üç seçeneğin tümünü sunmaktadır.
Bir sistem seçme sürecinde müşterinin, hedeflere ulaşmada kritik olan işlevlerin bir listesini belirlemesi gerekir.
Bundan sonra, liste öğelerini yukarıda açıklanan şemaya göre üç gruba dağıtmanız gerekecektir. Bu durumda, standart konfigürasyonda maksimum miktarda kritik işlevselliğe sahip olan ürünleri seçmelisiniz. Eksik işlevsellik, daha ayrıntılı ayarlarla ve gelişmiş yapılandırmanın kullanılmasıyla tamamlanmalıdır. Özel değişikliklere yalnızca ilk iki seçeneğin olanakları tükendiğinde ve kritik görevlerin başka şekilde çözülemeyeceği durumlarda başvurulması tavsiye edilir.
Antonina Bukina, müşteri hizmetleri müdürü, InterTrust şirketi
Standart ve özel bir elektronik belge yönetim sisteminin biraz tek taraflı karşılaştırmalı açıklaması, makalede ele alınmayan oldukça önemli noktalarla desteklenmelidir.
“Standart EDMS” ile “kutulu EDMS” kavramları arasına “eşit” koymanın mümkün olmadığını özellikle vurgulamak gerekir. Bunlar farklı karşılaştırmalı kategorilerdir. Detaylara girmeden şunları söyleyebiliriz:
a) kutulu EDMS (kutulu bir elektronik belge yönetim sistemi, değişiklik olasılığını ima etmez, "olduğu gibi" kurulur);
b) daha karmaşık EDMS (müşterinin talebi üzerine, müşterinin bireysel özelliklerine/ihtiyaçlarına uyacak şekilde özelleştirilebilir veya değiştirilebilir);
c) standart EDMS (sürümden sürüme geliştirilen temel işlevler, bir sürümden diğerine aktarılır, ek yeteneklerle zenginleştirilir - temel işlevsellik, kural olarak binlerce müşteri tarafından test edilmiştir);
d) EDMS, belirli bir kuruluş için sıfırdan geliştirildi.
Böylece standart EDMS, eğer paketli bir çözüm değilse, kolaylıkla
Seçmenin başka bir yolu daha var - kutulu bir ürünü kısa süreliğine test etmek
gerekirse yapılandırılır ve değiştirilir.
Standart bir elektronik belge yönetim sistemi, özellikle uzun süredir geliştirilmişse ve müşteriler tarafından aktif olarak kullanılıyorsa, müşteriyi ciddi risklerden kurtarır. Neden? Bir kişi tarafından değil, yüz, hatta bazen bin müşteri (sırasıyla birkaç bin kullanıcı) tarafından test edilmiştir ve bu da onun uygulanabilirliğini göstermektedir. İşlevselliğin tutarlılığı, farklı endüstri ve büyüklükteki kuruluşlarda yıllar süren endüstriyel kullanımla kanıtlanmıştır ve bu, bu tür yazılımların güvenilirliği hakkında konuşmamıza olanak tanır.
Ek olarak, standart EDMS, kural olarak, en iyi başarıları koruyarak ve en modern teknolojileri içerecek şekilde sürümden sürüme geliştirilir. Temelde, binlerce müşterinin en iyi deneyimini içeriyorlar, deneme yanılma yolu tamamlandı ve standart EDMS zaten tanındı.
Sıfırdan geliştirilen bir ürünün güvenirlik özelliği yoktur; başka bir firma tarafından çalıştırılması konusunda deneyim yoktur. İlk olacaksın.
EDMS'nin standart versiyonu ne kadar popüler olursa, piyasada onunla çalışma konusunda konfigürasyonu, modifikasyonu, desteği ve eğitimi konusunda o kadar fazla uzman bulacaksınız; bu, özel bir yaratıcının dar bir grubuna bağımlı kalmamanızı sağlayacaktır. çözüm.
Kısacası, standart bir çözümü uygulayarak uzun yıllar boyunca performansına güvenebilirsiniz.
Sözlük
Özgür yazılım (KAPALI), satış sonrasında sınırsız kurulum, başlatma, ücretsiz kullanım, çalışma, dağıtım ve değişiklik (geliştirme) haklarının alıcıya devredildiği yazılım ürünleridir.
Yineleme (Latince iteratio - “tekrar ediyorum”), kelimenin geniş anlamıyla, herhangi bir eylemin, olgunun veya sürecin tekrarıdır.
