עובדים לא רוצים תוכנה חדשה - האם הם צריכים ללכת על ההובלה או לעמוד בקו שלהם?

קפיצת מדרגה בתוכנה תהפוך בקרוב למחלה נפוצה מאוד של חברות. שינוי תוכנה אחת באחרת בגלל כל דבר קטן, קפיצה מטכנולוגיה לטכנולוגיה, התנסות בעסק חי הופך לנורמה. במקביל, מתחילה במשרד מלחמת אזרחים אמיתית: נוצרת תנועת התנגדות ליישום, פרטיזנים מנהלים עבודת חתרנות נגד השיטה החדשה, מרגלים מקדמים עולם חדש ואמיץ עם תוכנה חדשה, ניהול מהשריון של הפורטל הארגוני משדר על שלום, עבודה, מדדי KPI. מהפכה בדרך כלל מסתיימת בכישלון מוחלט מצד אחד.

אנחנו יודעים כמעט הכל על יישום, אז בואו ננסה להבין איך להפוך מהפכה לאבולוציה ולהפוך את היישום לשימושי וללא כאבים ככל האפשר. ובכן, או לפחות נגיד לך למה אתה עלול להיכנס בתהליך.

הדמיה אידיאלית של קבלת תוכנה חדשה על ידי עובדים מקור - Yandex.Images

יועצים זרים יתחילו את המאמר הזה בערך כך: "אם אתה מציע לעובדים שלך תוכנה איכותית שיכולה לשפר את עבודתם, להשפיע איכותית על הביצועים, אימוץ תוכנית או מערכת חדשה יקרה באופן טבעי." אבל אנחנו ברוסיה, אז הנושא של עובדים חשודים ומתלהמים מאוד רלוונטי. מעבר טבעי לא יעבוד, אפילו עם תוכנה מינימלית כמו מסנג'ר ארגוני או softphone.

מאיפה הרגליים של הבעיה?

כיום, בכל חברה מותקן גן חיות שלם של תוכנות (אנחנו לוקחים את המקרה הכללי, כי בחברות IT כמות התוכנה כפולה או משולשת, ובעיות ההתאמה חופפות חלקית והן מאוד ספציפיות): מערכות ניהול פרויקטים, CRM/ERP, לקוחות דואר אלקטרוני, מסרים מידיים, פורטל ארגוני וכו'. וזה לא סופר את העובדה שיש חברות שאפילו המעבר מדפדפן לדפדפן מתבצע על ידי כל הצוות ללא יוצא מן הכלל (ויש גם צוותים שמבוססים לחלוטין על Internet Explorer Edge). באופן כללי, ישנם מספר מצבים שעבורם המאמר שלנו עשוי להיות שימושי:

• תהליך האוטומציה העיקרית של קבוצת משימות מסוימת מתרחש: ה-CRM/ERP הראשון מיושם, פורטל ארגוני נפתח, מערכת לתמיכה טכנית מותקנת וכו';
• תוכנה אחת מוחלפת באחרת מסיבה כלשהי: התיישנות, דרישות חדשות, קנה מידה, שינוי פעילות וכו';
• מודולים של המערכת הקיימת נבנים למטרות פיתוח וצמיחה (למשל, חברה פתחה ייצור והחליטה לעבור מ RegionSoft CRM Professional על RegionSoft CRM Enterprise Plus עם פונקציונליות מקסימלית);
• מתבצע עדכון ממשק ותוכנה פונקציונלי מרכזי.

כמובן, שני המקרים הראשונים הם הרבה יותר חריפים ואופייניים בביטוייהם, שימו לב אליהם במיוחד.

לכן, לפני שאתם מתחילים לעבוד עם הצוות (שכבר חשד שיהיו שינויים בקרוב), נסו להבין מהן הסיבות האמיתיות לשינוי התוכנה והאם אתם מסכימים שהשינויים כה נחוצים.

• התוכנית הישנה קשה לעבודה: היא יקרה, לא נוחה, לא מתפקדת, כבר לא עונה על הדרישות שלך, לא מתאימה לקנה המידה שלך וכו'. זהו צורך אובייקטיבי.
• הספק הפסיק לתמוך במערכת, או שתמיכה ושינויים הפכו לסדרה אינסופית של אישורים וריקון כסף. אם העלויות שלכם עלו משמעותית, ובעתיד הן מבטיחות לגדול עוד יותר, אין למה לחכות, צריך לקצץ. כן, גם מערכת חדשה תעלה כסף, אבל בסופו של דבר אופטימיזציה תעלה פחות מתמיכה כזו.
• שינוי תוכנה הוא גחמה של אדם אחד או קבוצת עובדים. למשל, ה-CTO רוצה החזרה לאחור ועושה שתדלנות להכנסת מערכת חדשה ויקרה יותר - זה קורה בחברות גדולות. דוגמה נוספת: מנהל פרויקט דוגל בשינוי של אסאנה ל-Basecamp, ואז ב-Basecamp ל-Jira, ובמורכב של Jira ל-Wrike. לעתים קרובות המניע היחיד להגירות כאלה הוא להשוויץ בעבודתם העמוסה ולשמור על מעמדו. במקרים כאלה יש לקבוע את מידת ההכרח, המניעים וההצדקה וככלל, בהחלטה חזקה על סירוב לשינויים.

אנחנו מדברים על הסיבות למעבר מתוכנה אחת לאחרת, ולא על אוטומציה ראשונית – רק כי אוטומציה היא הכרחית אפריורית. אם החברה שלך עושה משהו באופן ידני ושגרתי אבל יכול להיות אוטומטי, אתה פשוט מבזבז זמן, כסף וכנראה גם נתוני חברה יקרים. הפוך אותו לאוטומטי!

איך אפשר לחצות: את הזינוק הגדול או את הנמר הכופף?

בפרקטיקה העולמית יש שלוש אסטרטגיות עיקריות למעבר לתוכנה חדשה ולהסתגלות אליה - והן נראות לנו מאוד מתאימות, אז בואו לא נמציא את הגלגל מחדש.

המפץ הגדול

אימוץ בשיטת "המפץ הגדול" הוא המעבר הקשה ביותר האפשרי, כאשר קובעים תאריך מדויק ומבצעים העברה חדה, ומשביתים את התוכנה הישנה ב-100%.

Pros

+ כולם עובדים במערכת אחת, אין צורך לסנכרן נתונים, העובדים לא צריכים לפקח על שני ממשקים בבת אחת.
+ פשטות למנהל - הגירה אחת, משימה אחת, תמיכה במערכת אחת.
+ כל השינויים האפשריים מתרחשים בנקודת זמן אחת ומורגשים כמעט מיד - אין צורך לבודד מה ובאיזה פרופורציה השפיעו על הפריון, מהירות הפיתוח, המכירות וכו'.

חסרונות

- עובד בהצלחה רק עם תוכנות פשוטות: צ'אטים, פורטל ארגוני, מסרים מיידיים. אפילו מייל כבר יכול להיכשל, שלא לדבר על מערכות ניהול פרויקטים, CRM/ERP ומערכות רציניות אחרות.
- הגירה נפיצה ממערכת גדולה לאחרת תגרום בהכרח לכאוס.

הדבר החשוב ביותר עבור סוג זה של מעבר לסביבת עבודה חדשה הוא הכשרה.

ריצה מקבילה

התאמה מקבילה לתוכנה היא שיטת מעבר רכה ואוניברסלית יותר, שבה נקבע פרק זמן שבו שתי המערכות יפעלו בו זמנית.

Pros

+ למשתמשים יש מספיק זמן להתרגל לתוכנה החדשה תוך עבודה מהירה בתוכנה הישנה, ​​למצוא מקבילות ולהבין את ההיגיון החדש של אינטראקציה עם הממשק.
+ במקרה של בעיות פתאומיות העובדים ממשיכים לעבוד במערכת הישנה.
+ הדרכת משתמשים פחות קפדנית ובדרך כלל זולה יותר.
+ אין כמעט תגובה שלילית מהעובדים - אחרי הכל, הם לא נשללו מהכלים הרגילים שלהם או דרך הפעולה שלהם (אם מתרחשת אוטומציה בפעם הראשונה).

חסרונות

— בעיות ניהול: תמיכה בשתי המערכות, סנכרון נתונים, ניהול אבטחה בשני יישומים בו זמנית.
— תהליך המעבר נמשך בלי סוף - העובדים מבינים שנותר להם כמעט נצח, והם יכולים להאריך עוד קצת את השימוש בממשק המוכר.
- בלבול משתמש - שני הממשקים מבלבלים וגורמים לשגיאות תפעול ונתונים.
- כסף. אתה משלם על שתי המערכות.

אימוץ בשלבים

התאמה שלב אחר שלב היא האפשרות הרכה ביותר למעבר לתוכנה חדשה. המעבר מתבצע באופן פונקציונלי, בפרקי זמן מוגדרים ולפי מחלקות (לדוגמה, החל מה-1 ביוני אנו מוסיפים לקוחות חדשים רק למערכת ה-CRM החדשה, מה-20 ביוני אנו מבצעים עסקאות במערכת החדשה, עד ה-1 באוגוסט אנו מעבירים יומנים ומקרים, ועד ה-30 בספטמבר אנו משלימים את ההגירה היא תיאור גס מאוד, אבל באופן כללי ברור).

Pros

+ מעבר מאורגן, עומס מבוזר בין מנהלי מערכת ומומחים פנימיים.
+ למידה מתחשבת ומעמיקה יותר.
+ אין התנגדות לשינוי, כי הוא מתרחש בצורה עדינה ככל האפשר.

חסרונות - בערך כמו במעבר מקביל.

אז עכשיו, רק מעבר הדרגתי?

שאלה הגיונית, תסכימו. למה לעשות קצת טרחה נוספת כשאפשר לקבוע לוח זמנים ולפעול לפי תוכנית ברורה? למעשה, לא הכל כל כך פשוט.

• מורכבות תוכנה: אם אנחנו מדברים על תוכנה מורכבת (לדוגמה, מערכת CRM), אז התאמת פאזה מתאימה יותר. אם התוכנה פשוטה (מסנג'ר, פורטל ארגוני), אז מודל מתאים הוא כאשר מכריזים על התאריך ומנטרלים את התוכנה הישנה ביום המיועד (אם יתמזל מזלכם, לעובדים יהיה זמן לשלוף את כל המידע שהם צריכים , ואם אתה לא סומך על מזל, אז אתה צריך לספק את הנתונים הדרושים לייבוא ​​אוטומטי מהמערכת הישנה לחדשה, אם זה אפשרי מבחינה טכנית).
• מידת הסיכון לחברה: ככל שהיישום מסוכן יותר, כך הוא צריך להיות איטי יותר. מצד שני, עיכוב הוא גם סיכון: למשל, אתה עובר ממערכת CRM אחת לאחרת, ובתקופת המעבר אתה נאלץ לשלם על שתיהן, ובכך להגדיל את העלויות והעלות של הטמעת המערכת החדשה, אשר פירושו שתקופת ההחזר מתארכת.
• מספר עובדים: המפץ הגדול בהחלט לא מתאים אם אתה צריך לשנות ולהגדיר פרופילי משתמשים רבים. למרות שיש מקרים בהם הטמעה מהירה במיוחד היא יתרון לחברה גדולה. אפשרות זו עשויה להתאים למערכות המשמשות עובדים רבים, אך ייתכן שאין להן דרישות מכיוון שלא נועדה התאמה אישית. אבל שוב, זהו מפץ גדול עבור משתמשי הקצה ועבודה ענקית צעד אחר צעד עבור אותו שירות IT (למשל, מערכת חיוב או גישה).
• תכונות של יישום התוכנה שנבחרה (עדכון וכו'). לעיתים היישום הוא בתחילה שלב אחר שלב - עם איסוף דרישות, חידוד, הדרכה וכו'. לדוגמה, מערכת CRM זה תמיד מיושם בהדרגה, ואם מישהו מבטיח לך "יישום ותצורה תוך 3 ימים או אפילו 3 שעות" - זכור את המאמר הזה ועקוף שירותים כאלה: התקנה ≠ יישום.

שוב, אפילו לדעת את הפרמטרים המפורטים, אי אפשר בהחלט ללכת בדרך זו או אחרת. העריכו את הסביבה הארגונית שלכם - זה יעזור לכם גם להבין את מאזן הכוחות וגם לקבוע איזה מודל (או שילוב של חלק מהמרכיבים שלהם) מתאים לכם.

סוכני השפעה: מהפכה או אבולוציה

הדבר הראשון שכדאי לשים לב אליו הוא העובדים שיושפעו מהטמעת תוכנות חדשות. למעשה, הבעיה שאנו שוקלים כעת היא גורם אנושי גרידא, כך שלא ניתן להימנע מניתוח ההשפעה על העובדים. כבר הזכרנו כמה מהם לעיל.

• ראשי החברה קובעים כיצד התוכנה החדשה תתקבל בדרך כלל. וזה לא המקום לנאומי קידום מכירות ונאומים לוהטים – חשוב להראות בדיוק את הצורך בשינוי, להעביר את הרעיון שזו רק בחירה בכלי מגניב ונוח יותר, כמו החלפת מחשב נייד ישן. הטעות הכי גדולה של ההנהלה במצב כזה היא לשטוף ידיים ולסגור את עצמם: אם ההנהלה לא צריכה אוטומציה של החברה, למה זה צריך לעניין את העובדים? להיות בתהליך.
• מנהלי מחלקות (מנהלי פרויקטים) הם חוליית ביניים שחייבת להשתתף בכל התהליכים, לנהל חוסר שביעות רצון, להראות רצון ועבודה דרך כל התנגדות של עמיתים ולקיים הכשרה איכותית ומעמיקה.
• שירות IT (או מנהלי מערכות) - במבט ראשון, אלו הם התינוקות המוקדמים שלך, הכי סתגלניים וסתגלניים, אבל... לא. לא פעם, בעיקר בחברות קטנות ובינוניות, מנהלי מערכות מתנגדים לכל שינוי (חיזוק) בתשתית ה-IT, והדבר אינו נובע מהצדקה טכנית כלשהי, אלא מעצלנות וחוסר רצון לעבוד. מי מאיתנו לא חיפש דרכים להימנע מעבודה? אבל זה לא יהיה לרעת החברה כולה.
• משתמשי קצה, ככלל, רוצים לעבוד בצורה טובה ונוחה מצד אחד וכמו כל אדם חי, חוששים משינוי. הטענה המרכזית לגביהם היא כנה ופשוטה: למה אנחנו מכניסים/משנים, מהם גבולות הבקרה, איך תוערך העבודה, מה ישתנה ומה הסיכונים (אגב, כל אחד צריך להעריך את הסיכונים - למרות שאנחנו ספקים מערכות CRM, אבל אנחנו לא מתחייבים לומר שהכל תמיד הולך חלק: יש סיכונים בכל תהליך בתוך עסק).
• "רשויות" בתוך החברה הן פרטיזנים שיכולים להשפיע על עובדים אחרים. לא מדובר בהכרח באדם בעל תפקיד גבוה או ניסיון רב - במקרה של עבודה עם תוכנה, ה"רשות" עשויה להיות יודע-הכל מתקדם, שלמשל קרא שוב את ה-Br ויתחיל להפחיד. כולם על כמה רע הכל יהפוך. אולי אפילו לא תהיה לו מטרה להרוס את תהליך היישום או המעבר - רק שוויון ורוח ההתנגדות - והעובדים יאמינו לו. אתה צריך לעבוד עם עובדים כאלה: להסביר, לשאול, ובמקרים קשים במיוחד, לרמוז על ההשלכות.

יש מתכון אוניברסלי לבדיקה אם משתמשים באמת מפחדים ממשהו או שיש להם פרנויה קבוצתית בהובלת מנהיג נבון. שאלו אותם על הסיבות לחוסר שביעות רצון, על חששות - אם זו לא חוויה או דעה אישית, ויכוחים יתחילו לזרום לאחר 3-4 שאלות הבהרה.

שני גורמים חשובים להתגברות מוצלחת על "תנועת ההתנגדות".

1. לספק הדרכה: ספק ופנימי. ודאו שהעובדים באמת מבינים הכל, שלטו בו, וללא קשר לרמת ההכשרה שלהם, מוכנים להתחיל לעבוד. תכונה חובה של הדרכה היא הוראות מודפסות ואלקטרוניות (תקנות) והתיעוד המלא ביותר על המערכת (ספקים שמכבדים את עצמם משחררים אותו יחד עם התוכנה ומספקים אותו בחינם).
2. חפש תומכים ובחר משפיענים. מומחים פנימיים ומאמצים מוקדמים הם מערכת התמיכה שלך, הן מחנכות ומפיגות ספקות. ככלל, העובדים עצמם שמחים לעזור לעמיתיהם ולהכיר להם תוכנות חדשות. המשימה שלך היא לשחרר אותם באופן זמני מעבודתם או לתת להם בונוס הגון עבור עומס העבודה החדש שלהם.

למה צריך לשים לב?

1. עד כמה העובדים מושפעים מהשינויים? (באופן יחסי, אם מחר ימציאו תוכנית ראיית חשבון חדשה, חס וחלילה תכניסו את האף למחלקת הנהלת החשבונות עם נשים מעל גיל 50 ותציעו מעבר מ-1C, לא תצאו בחיים).
2. עד כמה יושפעו זרימות עבודה? זה דבר אחד לשנות את המסנג'ר בחברה של 100 איש, דבר אחר הוא להטמיע מערכת CRM חדשה, שמבוססת על תהליכי מפתח בחברה (וזה לא רק מכירות, למשל, הטמעת RegionSoft CRM במהדורות בכירות זה משפיע על ייצור, מחסנים, שיווק ומנהלים בכירים שיחד עם הצוות יבנו תהליכים עסקיים אוטומטיים).
3. האם ניתנה הכשרה ובאיזה רמה?

המעבר ההגיוני היחיד במערכת החשיבה הארגונית

מה יחסוך את המעבר/הטמעה של תוכנה חדשה?

לפני שנספר לכם אילו נקודות מפתח יעזרו לכם לעבור בנוחות לתוכנה חדשה, הרשו לנו להסב את תשומת לבכם לנקודה אחת. יש משהו שבהחלט אסור לעשות - אין צורך להפעיל לחץ על העובדים ו"להניע" אותם על ידי מניעת בונוסים, סנקציות מנהליות ומשמעתיות. זה לא ישפר את התהליך, אבל היחס של העובדים יחמיר: אם ידחפו, אז תהיה שליטה; אם הם מכריחים אותך, זה אומר שהם לא מכבדים את האינטרס שלנו; אם הם כופים את זה בכוח, זה אומר שהם לא סומכים עלינו ועל העבודה שלנו. לכן, אנו עושים הכל בצורה ממושמעת, ברורה, מוכשרת, אך ללא לחץ או כפייה מיותרת.

חייבת להיות לך תוכנית פעולה מפורטת

כל השאר אולי לא קיים, אבל חייבת להיות תוכנית. יתרה מכך, התכנית מתכווננת, מעודכנת, ברורה ובלתי נמנעת, בו זמנית נגישה לדיון ושקופה לכל העובדים המעוניינים בכך. אי אפשר לתקשר באופן הנחיות שמשעה 8 בבוקר עד 10 בבוקר יש הישג, ובשעה 16:00 יש מלחמה עם אנגליה, חשוב לראות את כל התוכנית בפרספקטיבה.

התוכנית חייבת לשקף בהכרח את הדרישות של העובדים שיהיו משתמשי קצה – כך כל עובד יידע בדיוק מה התכונה הרצויה ובאיזה שעה יוכל להשתמש בה. יחד עם זאת, תוכנית המעבר או היישום איננה סוג של מונוליט בלתי משתנה; יש צורך להשאיר את האפשרות לסיים את התוכנית ולשנות את תכונותיה (אך לא בצורה של זרם אינסופי של עריכות ו"רצונות" חדשים) ולא בצורה של שינוי מתמיד במועדים).  

מה צריך להיות בתוכנית?

1. אבני הדרך העיקריות (שלבים) המעבר - מה צריך לעשות.
2. נקודות מעבר מפורטות לכל שלב - כיצד יש לעשות זאת.
3. נקודות מפתח ודיווח עליהן (תיאום שעות) - כיצד יימדד מה שנעשה ומי צריך להיות בנקודת הבקרה.
4. אנשים אחראיים הם אנשים שאפשר לפנות אליהם ולשאול מהם שאלות.
5. מועדים הם ההתחלה והסוף של כל שלב ושל התהליך כולו.
6. תהליכים מושפעים – אילו שינויים יתרחשו בתהליכים עסקיים, מה צריך לשנות יחד עם ההטמעה/המעבר.
7. ההערכה הסופית היא סט של אינדיקטורים, מדדים או אפילו הערכות סובייקטיביות שיסייעו להעריך את היישום/המעבר שהתרחש.
8. תחילת הפעילות היא התאריך המדויק בו כל החברה תצטרף לתהליך האוטומטי המעודכן ותעבוד במערכת החדשה.

נתקלנו במצגות של מיישמים בהן הקו האדום הוא עצות: יישמו בכוח, התעלמו מהתגובה, אל תדברו עם העובדים. אנחנו נגד גישה זו, והנה הסיבה.

הבט בתמונה שלמטה:

עכבר חדש, מקלדת חדשה, דירה, רכב ואפילו עבודה הם אירועים נעימים ומשמחים, חלקם אפילו הישגים. והמשתמש הולך ליאנדקס כדי לגלות איך להתרגל אליו ולהסתגל. איך להיכנס לדירה חדשה ולהבין שהיא שלך, לפתוח את הברז בפעם הראשונה, לשתות תה, ללכת לישון בפעם הראשונה. איך לעלות מאחורי ההגה ולהתיידד עם מכונית חדשה, שלך, אבל עד עכשיו כל כך זרה. תוכנה חדשה במקום העבודה אינה שונה מהמצבים המתוארים: עבודתו של העובד לעולם לא תהיה זהה. לכן, יישם, התאימו, צמיחו עם תוכנה יעילה חדשה. וזה מצב שעליו אפשר לומר: מהרו לאט.

מקור: www.habr.com