הרצון לפתח מול הצורך לפקח

חדשנות טכנולוגית וסדר פנימי בארגון – הידורו שניהם יחדיו?

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

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

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

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

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

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

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

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

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

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

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

להלן מספר פעולות המסייעות להגיע לאותו דו שיח ואיזון בין הנהלה של ארגון להנהלת IT:

  • הקפדה על הכנה ועדכון של תכנית אסטרטגית למחשוב רב שנתית, ובמסגרת זו, פריסה רחבה ככל האפשר של השקעות בטכנולוגיות חדשות. יש לזכור כי במקביל לפיתוי לחדש ולהוביל טכנולוגית ישנם סיכונים לא מעטים באימוץ מהיר מידי של טכנולוגיות אלו. אם ניצמד לדוגמא מעולם ה- Mobile, השאיפה תהיה לפרוס את אימוץ הטכנולוגיה ואפליקציות רלוונטיות על פני מספר שנים תוך הסתכלות רחבה על המתרחש בשוק. בתוך כך נשאף גם לקדם ולהתאים את מתודולוגית הפיתוח, הנהלים, שיטות העבודה לצרכים ולתוצרים השונים. נשאף ללוות את הפיתוח ע"י מומחים בתחומי איכות, אבטחת מידע ותאימות לרגולציות.
  • במסגרת תכניות עבודה שנתיות בהן מוגדר פורטפוליו הפרויקטים יש להקפיד על מיקוד עשייה ארגונית בהתאם לצרכים – אין ליצור מספר רב של פרויקטים.
  • גיבוש מתודולוגיות עבודה המבוססות על  Best practices מחד, אך לא בהכרח נצמדות רק לתפיסה אחת. ניתן לשלב את המיטב בראיית גוף ה- IT, דרך מספר תפיסות ומתודולוגיות. ניתן להמחיש פעולה זו ע"י דוגמא מעולם פיתוח והנדסת תוכנה. פיתוח קלאסי המבוסס על שלבי מחזור חיים סדורים (ייזום, אפיון, פיתוח, בדיקות, התקנה והרצה), מחד ופיתוח בהתאם למתודולוגיות זריזות – Agile Methodologies. שתי שיטות הפיתוח מגובות ב- Best Pratices מאוד ברורים ומפורטים. למרות זאת הצלחות נרשמות בעיקר בקרב גופי IT המשלבים את שתי שיטות הפיתוח בהתאם לאופיו של הפרויקט הנתון. 
  • התמודדות עם דרישות רגולטוריות ברמה מערכתית – חשוב להבין היטב את הדרישות של הרגולציות הרלוונטיות, ויש לזכור, כי עבודה על פי דרישות הרגולציה יכולה להתקבל בברכה ואף להיות מוערכת ע"י עובדי ה- IT ברמות שונות, כל עוד "ההפרעה" למשימות הפיתוח הינה מינימאלית. דרך לקדם פעולה זו הנה ע"י "חסכון" בפעולות בקרה הנדרשות בהקשר איכות, אבטחת מידע ו- SOX-ITGC ע"י כינוסן תחת רגולציה אחת ותוך הסכמה ותאום עם נציגי הרגולטורים השונים להתבסס על בקרות אלו. 
  • פיתוח מנגנונים "בולמים ומאזנים", תוך עידוד קידמה, חדשנות ויצירתיות. ניתן לדוגמא להשקיע בכלים ממוחשבים התומכים בתהליכי בקרה ופיתוח וישחררו את המפתח, איש התשתיות או בודק התוכנה מעיסוק במתן מענה לדרישות הבקרה.
  • הבנה מעמיקה של דרישות הרגולציה, בחינה, ניתוח והגדרה של השלכות, מיפוי תהליכים ובקרות נדרשים והטמעתם
  • הימנעות מאימוץ תפיסה או תקן כמכלול, כינוס תהליכי בקרה ככל הניתן, עידוד "קיצורי דרך" במידת הצורך, ושכלול תהליכי בקרה חיצוניים
  • לבסוף, חשוב לפתח את "אומנות" ההידברות בין גוף ה- IT לבין סביבתו – ההנהלה בכירה, הלקוחות הפנים ארגוניים, הספקים והרגולטורים.

נשמע מעניין? הירשמו לקבלת תכנים נוספים

או שתפו לחבריכם ברשתות החברתיות:

Share on facebook
Share on twitter
Share on linkedin

פוסטים נוספים שעשויים לעניין אותך: