על בחור אחד

הסיפור אמיתי, ראיתי הכל במו עיניי.

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

לפני כן הוא ניסה התמחויות שונות - 4 שנים בצרפת כמתכנת, מנהל פרויקטים, הוא הצליח להשלים 200 שעות, במקביל לקבל אחוזים מהפרויקט, לניהול ולעשות מעט מכירות. ניסיתי לפתח מוצרים בעצמי, הייתי ראש מחלקת IT בחברה גדולה עם 6 איש, ניסיתי אפשרויות שונות לשימוש במקצוע המוצע שלי - מתכנת 1C.

אבל כל התפקידים האלה היו מבוי סתום, בעיקר מבחינת הכנסה. באותה תקופה כולנו קיבלנו בערך אותו כסף ועבדנו באותם תנאים.

הבחור הזה תהה איך הוא יכול להרוויח יותר כסף מבלי למכור או ליצור עסק משלו.

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

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

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

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

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

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

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

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

אחר כך החליט לחזור על הניסוי והציע לבעלים לשפר תהליך בעייתי נוסף - אספקה. היו מחסור שלא אפשרו לנו לשלוח את הנפחים שלקוחותינו רצו. סיכמנו שתוך שנה הגירעונות יצטמצמו בחצי, והבחור ישלים גם 10-15 פרויקטים הקשורים ל-1C - לאוטומציה של תהליכים עסקיים שונים ושאר כפירות.

בשנה השנייה הכל הושלם שוב בהצלחה, הגירעונות ירדו ביותר מפי 2, כל פרויקטי ה-IT הושלמו בהצלחה.

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

איך זה היה? רשמית, הוא היה מנהל ה-IT. אבל מי הוא באמת היה קשה להבין. אחרי הכל, מה עושה מנהל IT? ככלל, הוא מנהל את תשתית ה-IT, מנהל מנהלי מערכות, מיישם מערכת ERP ומשתתף בישיבות הדירקטוריון.

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

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

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

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

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

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

אבל הבחור הזה היה מוזר. זה כמו, שבו ותהיה מאושר, החיים טובים. אבל לא. הוא החליט להרהר.

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

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

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

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

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

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

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

ראשית, מתכנתים מכירים את תחומי הנושא של העסק, והם מכירים אותם טוב יותר מכל שאר האנשים בחברה.

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

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

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

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

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

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

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

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

אבל הצלחנו לחלץ משהו שימושי מהמונולוגים שלו. אני אגיד לך מה אני זוכר.

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

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

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

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

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

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

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

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

קח, הוא אמר, למשל, את Scrum או Agile. במונולוגים שלו, הבחור חזר פעמים רבות שלא כולם מבינים עד הסוף את המהות של Scrum. הוא גם קרא את ספרו של ג'ף סאתרלנד, שחלק מהאנשים מוצאים אותו "קריאה קלה". זה נראה לו כמו קריאה עמוקה, כי אחד מעקרונות היסוד של Scrum הוא ניהול איכות, זה כתוב ישירות בספר.

זה אומר על Toyota Production, על איך ג'ף סאתרלנד הראה את Scrum ביפן, איך זה השתרש שם וכמה זה היה קרוב לפילוסופיה שלהם. וסאת'רלנד דיבר על חשיבות התפקיד של ה-Scrum Master, על מחזור דמינג. תפקידו של ה-Scrum Master הוא להאיץ כל הזמן את התהליך. כל השאר שיש ב-Scrum – אספקה ​​מדורגת, שביעות רצון לקוחות, רשימת עבודה ברורה לתקופת הספרינט – חשוב גם הוא, אבל כל זה חייב לנוע מהר יותר ויותר. מהירות העבודה חייבת לעלות כל הזמן ביחידות שבהן היא נמדדת.

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

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

הוא גם המליץ ​​באופן אישי על מספר טכניקות. הוא כינה אותם יסודיים ויסודיים.

הראשון הוא ניהול גבולות.

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

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

אבל לרוב הבחור דיבר על שליטה. פשוט הייתה לו איזושהי מוזרות בנושא הזה.

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

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

הדבר הראשון שרע הוא המספרים. יש מעט מהם והם באיכות נמוכה.

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

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

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

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

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

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

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

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

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

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

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

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

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

כי המנהיג הרוסי לא יוותר על חלק מכוחו למתחרה.

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

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

קצת פחות, אבל עדיין יותר מדי, לדעתי, הוא דיבר על Scrum.

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

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

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

ובכן, בחלק העליון שלו היה TOS (תיאוריית מגבלות המערכת).

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

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

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

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

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

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

לדבריו, העבודה של מתכנת ו"משפר תהליכים עסקיים" דומות מאוד. ועזב.

מקור: www.habr.com