Yazılım sıçraması yakında şirketlerde çok yaygın bir hastalık haline gelecek. En ufak bir şey yüzünden bir yazılımı diğerine değiştirmek, teknolojiden teknolojiye atlamak, canlı bir işletmeyi denemek norm haline geliyor. Aynı zamanda ofiste gerçek bir iç savaş başlıyor: uygulamaya karşı bir direniş hareketi oluşuyor, partizanlar yeni sisteme karşı yıkıcı çalışmalar yürütüyor, casuslar yeni yazılımla cesur yeni bir dünyayı tanıtıyor, yönetim zırhlı arabadan yapılıyor. kurumsal portal barış, emek, KPI'lar hakkında yayın yapıyor. Bir devrim genellikle bir tarafta tam bir başarısızlıkla sonuçlanır.
Uygulama hakkında hemen hemen her şeyi biliyoruz, bu yüzden bir devrimi nasıl evrime dönüştürebileceğimizi ve uygulamayı mümkün olduğunca faydalı ve acısız hale nasıl getirebileceğimizi bulmaya çalışalım. En azından bu süreçte neler yaşayabileceğinizi size söyleyeceğiz.
Çalışanların yeni yazılımı kabul etmesinin ideal görselleştirilmesi Kaynak - Yandex.Görseller
Yabancı danışmanlar bu yazıya şöyle başlarlardı: “Çalışanlarınıza işlerini iyileştirebilecek, performans üzerinde niteliksel etkisi olan kaliteli bir yazılım sunarsanız, yeni bir program veya sistemin benimsenmesi doğal olarak gerçekleşecektir.” Ancak biz Rusya'dayız, dolayısıyla şüpheli ve saldırgan çalışanlar meselesi çok önemli. Kurumsal mesajlaşma veya yazılım telefonu gibi minimal yazılımlarla bile doğal bir geçiş işe yaramayacaktır.
Sorunun ayakları nereden geliyor?
Bugün, her şirkette yüklü bir yazılım hayvanat bahçesi bulunmaktadır (genel durumu ele alıyoruz, çünkü BT şirketlerinde yazılım miktarı iki veya üç kat fazladır ve uyum sorunları kısmen örtüşmektedir ve çok spesifiktir): proje yönetim sistemleri, CRM/ERP, e-posta istemcileri, anlık mesajlaşma programları, kurumsal portal vb. Ve bu, tarayıcıdan tarayıcıya geçişin bile istisnasız tüm ekip tarafından gerçekleştirildiği şirketlerin olduğu gerçeğini saymıyor (ve ayrıca tamamen Internet Explorer Edge'i temel alan ekipler de var). Genel olarak makalemizin yararlı olabileceği birkaç durum vardır:
- Bazı görev gruplarının birincil otomasyon süreci vardır: ilk CRM/ERP uygulanıyor, kurumsal bir portal açılıyor, teknik destek sistemi kuruluyor, vb.;
- bir yazılım bazı nedenlerden dolayı bir başkasıyla değiştirilir: eskime, yeni gereksinimler, ölçeklendirme, faaliyet değişikliği vb.;
- Mevcut sistemin modülleri gelişme ve büyüme amacıyla oluşturuluyor (örneğin bir firmanın üretime geçmesi ve sistemden geçiş kararı alması) üzerinde maksimum işlevselliğe sahip);
- Önemli bir arayüz ve işlevsel yazılım güncellemesi yapılıyor.
Elbette ilk iki vaka tezahürlerinde çok daha akut ve tipiktir, onlara özellikle dikkat edin.
Bu nedenle, (yakında değişiklik olacağından zaten şüphelenen) ekiple çalışmaya başlamadan önce, yazılımı değiştirmenin gerçek nedenlerinin ne olduğunu ve değişikliklerin bu kadar gerekli olduğu konusunda hemfikir olup olmadığınızı anlamaya çalışın.
- Eski programla çalışmak zordur: pahalıdır, kullanışsızdır, işlevsel değildir, artık gereksinimlerinizi karşılamamaktadır, ölçeğinize uygun değildir vb. Bu nesnel bir zorunluluktur.
- Satıcı sistemi desteklemeyi bıraktı veya destek ve modifikasyonlar sonsuz sayıda onaya ve para kaybına dönüştü. Maliyetleriniz önemli ölçüde arttıysa ve gelecekte daha da artacağını vaat ediyorlarsa, bekleyecek bir şey yok, kesmeniz gerekiyor. Evet, yeni bir sistem de paraya mal olacaktır, ancak sonuçta optimizasyon bu tür bir destekten daha ucuza mal olacaktır.
- Yazılımı değiştirmek bir kişinin veya bir grup çalışanın isteğidir. Örneğin, CTO geri dönüş istiyor ve yeni, daha pahalı bir sistemin uygulamaya konması için lobi yapıyor - bu büyük şirketlerde oluyor. Başka bir örnek: bir proje yöneticisi Asana'nın Basecamp'a, ardından Basecamp'ın Jira'ya ve Jira'nın da Wrike'a değiştirilmesini savunuyor. Çoğu zaman bu tür göçlerin tek nedeni yoğun işleriyle gösteriş yapmak ve konumlarını korumaktır. Bu gibi durumlarda, gerekliliğin, gerekçelerin ve gerekçelerin derecesini belirlemek ve kural olarak, güçlü iradeli bir kararla değişiklikleri reddetmek gerekir.
Birincil otomasyondan değil, bir yazılımdan diğerine geçişin nedenlerinden bahsediyoruz - yalnızca otomasyonun önsel olarak gerekli olması nedeniyle. Şirketiniz manuel ve rutin bir şekilde bir şey yapıyorsa ancak otomatikleştirilebiliyorsa, yalnızca zaman, para ve büyük olasılıkla değerli şirket verilerini boşa harcıyorsunuz demektir. Otomatikleştirin!
Nasıl karşıya geçebilirsin: büyük sıçrayış mı yoksa çömelmiş kaplan mı?
Dünya pratiğinde, yeni yazılıma geçmek ve ona uyum sağlamak için üç ana strateji vardır ve bunlar bize çok uygun görünmektedir, o yüzden tekerleği yeniden icat etmeyelim.
Büyük patlama
"Büyük Patlama" yöntemini kullanarak benimseme, kesin bir tarih belirlediğinizde ve eski yazılımı% 100 devre dışı bırakarak keskin bir geçiş gerçekleştirdiğinizde mümkün olan en zor geçiştir.
Avantajları:
+ Herkes tek sistemde çalışır, veri senkronizasyonuna gerek yoktur, çalışanların aynı anda iki arayüzü izlemesine gerek yoktur.
+ Yönetici için basitlik - tek geçiş, tek görev, tek sistem desteği.
+ Tüm olası değişiklikler aynı anda gerçekleşir ve neredeyse anında fark edilir - verimliliği, geliştirme hızını, satışları vb. neyin ve hangi oranda etkilediğini izole etmeye gerek yoktur.
Eksileri
— Yalnızca basit yazılımlarla başarıyla çalışır: sohbetler, kurumsal portal, anlık mesajlaşma programları. Proje yönetim sistemleri, CRM/ERP ve diğer ciddi sistemlerin yanı sıra e-posta bile zaten başarısız olabilir.
— Büyük bir sistemden diğerine patlayıcı bir geçiş kaçınılmaz olarak kaosa neden olacaktır.
Yeni bir çalışma ortamına bu tür geçiş için en önemli şey eğitimdir.
Paralel Koşu
Yazılıma paralel adaptasyon, her iki sistemin aynı anda çalışacağı bir zaman diliminin belirlendiği, daha yumuşak ve daha evrensel bir geçiş yöntemidir.
Avantajları:
+ Kullanıcılar eski yazılımda hızlı bir şekilde çalışırken yeni yazılıma alışmak, paralellikler bulmak ve arayüzle etkileşimin yeni mantığını anlamak için yeterli zamana sahiptir.
+ Ani sorunlar yaşanması durumunda çalışanlar eski sistemde çalışmaya devam eder.
+ Kullanıcı eğitimi daha az titizdir ve genellikle daha ucuzdur.
+ Çalışanlardan neredeyse hiçbir olumsuz tepki gelmiyor - sonuçta, her zamanki araçlarından veya işleri yapma yöntemlerinden mahrum değillerdi (eğer otomasyon ilk kez meydana geliyorsa).
Eksileri
— Yönetim sorunları: her iki sistem için destek, veri senkronizasyonu, aynı anda iki uygulamada güvenlik yönetimi.
— Geçiş süreci sonsuz bir şekilde uzuyor - çalışanlar neredeyse sonsuzluğa sahip olduklarının farkına varıyorlar ve tanıdık arayüzün kullanımını biraz daha genişletebilirler.
- Kullanıcı Karışıklığı - İki arayüz kafa karıştırıcıdır ve operasyonel hatalara ve veri hatalarına neden olur.
- Para. Her iki sistem için de ödeme yaparsınız.
Aşamalı Benimseme
Adım adım adaptasyon, yeni yazılıma geçiş için en yumuşak seçenektir. Geçiş, işlevsel olarak, belirlenen sürelerde ve departman bazında gerçekleştirilir (örneğin, 1 Haziran'dan itibaren yeni müşterileri sadece yeni CRM sistemine ekliyoruz, 20 Haziran'dan itibaren yeni sistemde işlem yapıyoruz, 1 Ağustos'a kadar takvimleri aktarıyoruz) ve vakalar ve 30 Eylül'e kadar göçü tamamladığımız çok kaba bir tanımdır, ancak genel olarak açıktır).
Avantajları:
+ Organize geçiş, yöneticiler ve iç uzmanlar arasında yük dağıtılması.
+ Daha düşünceli ve derinlemesine öğrenme.
+ Değişime direnç yoktur çünkü mümkün olduğu kadar yumuşak bir şekilde gerçekleşir.
Eksileri - paralel geçişle yaklaşık olarak aynı.
Peki şimdi, sadece kademeli bir geçiş mi?
Mantıklı bir soru, buna katılacaksınız. Bir program yapıp net bir plana göre hareket etmek varken neden ekstra güçlükle karşılaşasınız ki? Aslında her şey o kadar basit değil.
- Yazılım karmaşıklığı: karmaşık bir yazılımdan bahsediyorsak (örneğin, ), o zaman faz adaptasyonu daha uygundur. Yazılım basitse (mesajcı, kurumsal portal), tarihi duyurmanız ve belirlenen günde eski yazılımı devre dışı bırakmanız uygun bir modeldir (şanslıysanız, çalışanların ihtiyaç duydukları tüm bilgileri almak için zamanları olacaktır). ve eğer şansa güvenmiyorsanız, teknik olarak mümkünse, gerekli verilerin eski sistemden yenisine otomatik olarak aktarılmasını sağlamanız gerekir).
- Şirket için risk derecesi: Uygulama ne kadar riskli olursa, o kadar yavaş olmalıdır. Öte yandan, gecikme de bir risktir: örneğin, bir CRM sisteminden diğerine geçiş yapıyorsunuz ve geçiş döneminde her ikisi için de ödeme yapmak zorunda kalıyorsunuz, böylece yeni sistemin uygulanmasının maliyeti ve maliyeti artıyor. geri ödeme süresinin uzatılması anlamına gelir.
- Çalışan sayısı: Çok sayıda kullanıcı profilini ölçeklendirmeniz ve yapılandırmanız gerekiyorsa Big Bang kesinlikle uygun değildir. Her ne kadar ultra hızlı uygulamanın büyük bir şirket için avantaj sağladığı durumlar olsa da. Bu seçenek birçok çalışan tarafından kullanılan sistemler için uygun olabilir ancak özelleştirme amaçlanmadığından gereksinimleri olmayabilir. Ancak yine de bu, son kullanıcılar için büyük bir patlamadır ve aynı BT hizmeti (örneğin, faturalandırma veya erişim sistemi) için adım adım yapılan devasa bir çalışmadır.
- Seçilen yazılımın uygulanmasının özellikleri (revizyon vb.). Bazen uygulama, gereksinimlerin toplanması, iyileştirilmesi, eğitimi vb. ile başlangıçta aşamalı olarak gerçekleştirilir. Örneğin, her zaman aşamalı olarak uygulanır ve eğer birisi size "3 gün, hatta 3 saat içinde uygulama ve yapılandırma" sözü verirse - bu makaleyi hatırlayın ve bu tür hizmetleri atlayın: kurulum ≠ uygulama.
Yine, listelenen parametreleri bilseniz bile, kişi kesinlikle şu ya da bu yolu izleyemez. Kurumsal ortamınızı değerlendirin; bu hem güç dengesini anlamanıza hem de hangi modelin (veya bunların bazı unsurlarının birleşiminin) sizin için doğru olduğunu belirlemenize yardımcı olacaktır.
Etki etkenleri: devrim veya evrim
Dikkat etmeniz gereken ilk şey yeni yazılımın uygulanmasından etkilenecek çalışanlardır. Aslında şu anda ele aldığımız sorun tamamen insan faktöründen kaynaklanıyor, dolayısıyla bunun çalışanlar üzerindeki etkisini analiz etmekten kaçınılamaz. Zaten yukarıda bazılarından bahsetmiştik.
- Yeni yazılımın genel olarak nasıl kabul edileceğini şirket liderleri belirler. Ve burası tanıtım konuşmalarının ve ateşli konuşmaların yeri değil - değişim ihtiyacını tam olarak göstermek, bunun sadece eski bir dizüstü bilgisayarı değiştirmekle aynı şekilde daha havalı ve daha kullanışlı bir araç seçmek olduğu fikrini iletmek önemlidir. Böyle bir durumda yönetimin en büyük hatası ellerini yıkayıp geri çekilmesidir: Yönetimin şirket otomasyonuna ihtiyacı yoksa, bu neden çalışanların ilgisini çeksin? Sürecin içinde olun.
- Departman başkanları (proje yöneticileri), tüm süreçlere katılması, memnuniyetsizlikleri yönetmesi, irade göstermesi ve meslektaşların her türlü itirazı üzerinde çalışması, kaliteli ve derinlemesine eğitim vermesi gereken bir ara halkadır.
- BT hizmeti (veya sistem yöneticileri) - ilk bakışta bunlar sizin ilk kuşlarınızdır, en uyumlu ve uyarlanabilir olanlardır, ancak... hayır. Çoğu zaman, özellikle küçük ve orta ölçekli şirketlerde, sistem yöneticileri BT altyapısında herhangi bir değişikliğe (güçlendirilmesine) karşı çıkarlar ve bu herhangi bir teknik gerekçeden değil, tembellikten ve çalışma isteksizliğinden kaynaklanmaktadır. Hangimiz iş yapmaktan kaçınmanın yollarını aramadık ki? Ancak bu tüm şirketin zararına olmasın.
- Son kullanıcılar, kural olarak, bir yandan iyi ve rahat çalışmak isterler ve yaşayan her insan gibi değişimden korkarlar. Onlar için temel argüman dürüst ve basit: neden getiriyoruz/değiştiriyoruz, kontrolün sınırları nelerdir, iş nasıl değerlendirilecek, ne değişecek ve riskler neler (bu arada herkes riskleri değerlendirmeli - satıcı olmamıza rağmen , ancak her şeyin her zaman sorunsuz gittiğini söylemeyi taahhüt etmiyoruz: bir işletmedeki her süreçte riskler vardır).
- Şirket içindeki “yetkililer” diğer çalışanları etkileyebilecek partizanlardır. Bu kişi mutlaka yüksek pozisyona veya kapsamlı deneyime sahip bir kişi olmak zorunda değildir - yazılımla çalışma durumunda, "yetkili", örneğin Habr'ı yeniden okumuş ve gözünü korkutmaya başlayacak, ileri düzeyde her şeyi bilen bir kişi olabilir. Herkes her şeyin ne kadar kötü olacağıyla ilgili. Uygulamayı veya geçiş sürecini bozmak gibi bir hedefi bile olmayabilir - sadece gösteriş ve direniş ruhu - ve çalışanlar ona inanacaktır. Bu tür çalışanlarla çalışmanız gerekir: açıklayın, sorgulayın ve özellikle zor durumlarda sonuçları ipucu verin.
Kullanıcıların gerçekten bir şeyden korkup korkmadıklarını veya bilgili bir liderin önderlik ettiği grup paranoyasına sahip olup olmadıklarını kontrol etmenin evrensel bir tarifi var. Onlara memnuniyetsizliğin nedenlerini, endişelerini sorun; eğer bu kişisel bir deneyim veya görüş değilse, 3-4 açıklayıcı sorudan sonra tartışmalar yağmaya başlayacaktır.
“Direniş hareketinin” başarıyla üstesinden gelinmesi için iki önemli faktör.
- Eğitim sağlayın: satıcı ve dahili. Çalışanların her şeyi gerçekten anladıklarından, bu konuda uzmanlaştıklarından ve eğitim düzeyleri ne olursa olsun çalışmaya başlamaya hazır olduklarından emin olun. Eğitimin zorunlu bir özelliği, basılı ve elektronik talimatlar (yönetmelikler) ve sistemdeki en eksiksiz belgelerdir (kendine saygılı satıcılar bunu yazılımla birlikte yayınlar ve ücretsiz olarak sağlar).
- Destekçileri arayın ve etkileyicileri seçin. Dahili uzmanlar ve ilk benimseyenler, hem eğitici hem de şüpheleri ortadan kaldıran destek sisteminizdir. Kural olarak, çalışanlar meslektaşlarına yardım etmekten ve onları yeni yazılımla tanıştırmaktan memnuniyet duyarlar. Göreviniz, onları geçici olarak işlerinden kurtarmak veya yeni iş yükleri için onlara makul bir ikramiye vermektir.
Neye dikkat etmeniz gerekiyor?
- Çalışanlar değişikliklerden ne kadar etkileniyor? (Nispeten konuşursak, eğer yarın yeni bir muhasebe programı icat ederlerse, Allah korusun, 50 yaş üstü hanımların olduğu muhasebe departmanına burnunuzu sokarsanız ve 1C'den geçiş önerirseniz, canlı çıkamazsınız).
- İş akışları ne kadar etkilenecek? 100 kişilik bir şirkette messenger'ı değiştirmek bir şeydir, başka bir şey de şirketteki temel süreçlere dayanan yeni bir CRM sistemi uygulamaktır (ve bu sadece satış değildir, örneğin, üst düzey sürümlerde üretim, depo, pazarlama ve ekiple birlikte otomatik iş süreçleri oluşturacak üst düzey yöneticileri etkiler).
- Eğitim verildi mi ve hangi düzeyde?
Kurumsal düşünce sistemindeki tek mantıklı geçiş
Yeni yazılımın geçişini/uygulanmasını ne kurtaracak?
Hangi önemli noktaların yeni yazılıma rahatça geçmenize yardımcı olacağını söylemeden önce bir noktaya dikkatinizi çekelim. Kesinlikle yapılmaması gereken bir şey var; çalışanlara baskı yapmaya, onları ikramiyelerden, idari ve disiplin yaptırımlarından mahrum bırakarak “motive etmeye” gerek yok. Bu, süreci daha iyi hale getirmeyecek ancak çalışanların tutumu daha da kötüleşecek: Eğer zorlarlarsa, o zaman kontrol olacaktır; Eğer sizi zorluyorlarsa bu bizim çıkarlarımıza saygı duymadıkları anlamına gelir; Eğer zorla dayatıyorlarsa bize ve yaptığımız işe güvenmiyorlar demektir. Bu nedenle her şeyi disiplinli, net, yetkin bir şekilde, ancak baskı veya gereksiz zorlama olmadan yapıyoruz.
Detaylı bir eylem planınız olmalı
Geriye kalan her şey olmayabilir ama bir plan olmalı. Üstelik plan ayarlanabilir, güncel, açık ve kaçınılmazdır, aynı zamanda ilgili tüm çalışanlar için tartışmaya açıktır ve şeffaftır. Sabah 8'den akşam 10'a kadar bir başarı olduğunu ve saat 16:00'da İngiltere ile savaşın olduğunu doğrudan iletmek imkansızdır, tüm planı perspektif içinde görmek önemlidir.
Plan mutlaka son kullanıcı olacak çalışanların gereksinimlerini yansıtmalıdır; böylece her çalışan tam olarak hangi özelliği istediğini ve onu ne zaman kullanabileceğini bilecektir. Aynı zamanda, geçiş veya uygulama planı bir tür değişmez monolit değildir; planı sonuçlandırma ve niteliklerini değiştirme olasılığını bırakmak gerekir (ancak sonsuz bir düzenleme akışı ve yeni "istekler" biçiminde değil) ve son teslim tarihlerinde sürekli bir değişiklik şeklinde değil).
Planda neler olmalı?
- Geçişin ana aşamaları (aşamaları) - yapılması gerekenler.
- Her aşama için ayrıntılı geçiş noktaları - nasıl yapılması gerektiği.
- Kilit noktalar ve bunların raporlanması (saatlerin mutabakatı) - yapılanların nasıl ölçüleceği ve kontrol noktasında kimin olması gerektiği.
- Sorumlu kişiler, başvurabileceğiniz ve soru sorabileceğiniz kişilerdir.
- Son teslim tarihleri, her aşamanın ve bir bütün olarak sürecin başlangıcı ve sonudur.
- Etkilenen süreçler - iş süreçlerinde ne gibi değişiklikler olacak, uygulama/geçişle birlikte nelerin değişmesi gerekiyor.
- Nihai değerlendirme, gerçekleşen uygulamanın/geçişin değerlendirilmesine yardımcı olacak bir dizi gösterge, ölçüm ve hatta öznel değerlendirmelerden oluşur.
- Operasyonun başlangıcı, tüm şirketin güncellenmiş otomatik sürece katılacağı ve yeni sistemde çalışacağı kesin tarihtir.
Uygulayıcıların kırmızı çizginin tavsiye olduğu sunumlarına rastladık: Zorla uygulayın, tepkiyi görmezden gelin, çalışanlarla konuşmayın. Biz bu yaklaşıma karşıyız ve nedeni de bu.
Aşağıdaki resme bakın:
Yeni bir fare, yeni bir klavye, bir daire, bir araba ve hatta bir iş hoş, neşeli olaylardır, hatta bazıları başarıdır. Kullanıcı da buna nasıl alışacağını ve uyum sağlayacağını öğrenmek için Yandex'e gidiyor. Yeni bir daireye nasıl girilir ve onun size ait olduğunu nasıl anlarsınız, musluğu ilk kez açın, çay içirin, ilk kez yatağa gidin. Direksiyonun arkasına nasıl geçilir ve yeni bir araba ile nasıl arkadaş olunur, sizinki, ama şimdiye kadar çok yabancı. İşyerindeki yeni yazılım anlatılan durumlardan farklı değil: Çalışanın işi asla eskisi gibi olmayacak. Bu nedenle yeni ve etkili yazılımları uygulayın, uyarlayın, büyütün. Bu da şöyle diyebileceğimiz bir durum: Yavaş yavaş acele edin.
Kaynak: habr.com