מערכות BPM

מערכות BPM

מדריך זה דן במערכות BPM (Business Process Management).

BPM היא תפיסת מחשוב לייצוג תהליכים עסקיים באמצעים ממוחשבים. הייצוג הממוחשב מאפשר לאנשי העסקים נראות (Visibility) טובה יותר של התהליכים וכתוצאה מכך גם קלות בשיפור התהליכים והתאמתם לצרכים העסקיים המשתנים.

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

מבוא

BPM ((Business Process Management היא תפיסה בה התהליכים העסקיים מנוהלים באמצעות תוכנה. כאשר ממומש BPM באירגון, משתמשים עסקיים יכולים לקבל ייצוג גרפי של התנהלות התהליכים העסקיים.  ייצוג זה מאפשר למשתמש העסקי לראות את :

 ·         סדר הפעילויות המרכיבות את התהליך,

 ·         ההתניות לביצוען,

 ·         המערכות הממוחשבות המעורבות בתהליך,

 ·         הפעילויות האנושיות הנדרשות לביצוע כחלק מהתהליך,

 ·         המידע הזורם במהלך ביצוע התהליך.

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

סוגי תהליכים

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

 ·         טווח התהליך

 ·         מהות התהליך

טווח התהליך

 ·         תהליכים בין אירגונים (B2B), למשל תהליך שרשרת אספקה.

 ·         תהליכים כלל אירגוניים (Enterprise Processes)

 ·         תהליך לקו עסקי (Business Line), למשל תהליך מתן ערבות בקוו עסקים עסקי בבנק.

 ·         תהליכים מחלקתיים, למשל תהליך במחלקת ביטוח חיים בחברת ביטוח.

 ·         תהליכים  בתוך יישום

 ·         תהליכי מיקרו  (Micro Processes)

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

מהות התהליך

 ·         תהליך אוטומטי - תהליך המתבצע באמצעות מערכות ממוחשבות בלבד.

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

 ·         תהליך מבוסס מסמכים - תהליך המבוצע במקביל לזרימה של מסמכים.

 ·         תהליכים הממומשים בחלקם באמצעות מנוע חוקים (Rules Based Engines)

BPM ו- Workflow

Workflow

Workflow מתאר את זרימת הנתונים וזרימת המסמכים במהלך ביצוע תהליך. מבוסס על תהליך פשוט של Routing - לאחר סיום משימה (Task), נעשה מעבר אוטומטי למשימה הבאה. 

BPM

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

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

מושגי יסוד

מחזור החיים של תהליך

 

להלן שלבי מחזור החיים של תהליך על פי סדר כרונולוגי:

 ·         ניתוח תהליך עסקי Business Process Analysis  

 ·         בניית קוד והרצת התהליך  Business Process Execution

 ·         מדידה ואופטימיזציה Business Process Monitoring

ניתוח תהליך עסקי

(Business Process Analysis)

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

 ·         בנית מודל - נבנה מודל של התהליך המתאר את כל המרכיבים, הפעילויות והמשימות המבוצעים במהלכו.

 ·         סימולציה - מבוצעת סימולציה של הרצת התהליך על מנת לתקף את נכונותו. במקרה בו הסימולציה מאתרת מודל לא מדויק של התהליך נבנה מודל משופר.

בניית קוד והרצת התהליך

(Business Process Execution)

מבוצע על ידי מומחי המחשוב של האירגון. מורכב משלושה שלבי משנה:

 ·         פיתוח קוד - מתבסס על המודל שפותח בשלב הניתוח העסקי.  הקוד יורד לרמת פירוט גבוהה יותר מאשר המודל.

 ·         Deployment - יצירת קוד שיכול להתבצע.

 ·         הרצה - הרצת התהליך  באופן קבוע על פי צרכי האירגון.

מדידה ואופטימיזציה

מדידה ואופטימיזציה

(Business Process Monitoring)

מורכב משני שלבים:

 ·         מדידה (BAM) - מדידה באמצעות לוח מחוונים (Dashboard) גרפי, המרכז על מסך אחד את ערכי  כל המדדים החשובים ברמה העסקית KPI (Key Performance Indicators) וברמת ביצוע התהליך.

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

 ·         אופטימיזציה - ניתוח תוצאות המדידה והצעה לתהליך משופר. הניתוח נעשה באמצעות כלים של בינה עסקית וכלים ייעודיים של בינה תהליכית (Process Intelligence).

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

ממודל לקוד ובחזרה

(Round Tripping)

בפיתוח  תהליכים ניתן להשתמש במודל על מנת ליצר קוד ובקוד על מנת ליצר מודל. במובן זה דומה BPM לסביבות פיתוח מבוססות כלי CASE או מבוססות UML. הגישה הנפוצה היא גשר דו-כווני Bidirectional Bridge)) באמצעותו באופן כמעט אוטומטי מוסב מודל לקוד וקוד למודל.

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

תשתית

מימוש BPM נעשה באמצעות שרת תוכנה המנהל את התהליכים. שרת התוכנה כולל הגדרות של אופן ניהול כל תהליך ותהליך , כגון:

 ·         מאיזה משימות (Tasks)  מורכב כל תהליך?

 ·         איזה מידע מועבר מפעילות לפעילות?

 ·         מה הם התנאים בהם יתבצע מעבר בין פעילות לפעילות?

 ·         איזה אירועים משפיעים על ביצוע התהליך ומה ההשפעה שלהם?

תהליכים אנושיים

תשתית המטפלת בתהליכים אנושיים כוללת בנוסף ליכולות הבסיסיות שצוינו לעיל את המרכיבים הבאים:

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

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

 ·          To Do List - רשימת פעילויות במופעי תהליכים עליהן אחראי עובד. מוצר ה- BPM צריך לתת עדיפויות לפעילויות על מנת שהעובד יתחיל את הטיפול בפעילויות בעלות עדיפות גבוהה.

 ·         מי רשאי לבצע את הפעילויות במופעים שאת העבודה עליהם התחיל עובד שנעדר וכיצד ידע מחליף  שעליו לבצע פעילויות במקום העובד הנעדר? הפעילויות האנושיות לא בהכרח מסתימות באותו יום. עובד עשוי להיעדר בימים שלאחר שהתחיל פעילות שלא הסתימה.

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

ארכיטקטורה

מימוש BPM מנסה להעביר את מערכות המחשוב באירגונים מתפיסה ממוקדת פונקציונאליות (Functional Centric) לתפיסה ממוקדת תהליכים (Process Centric).

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

ההפרדה של שכבת התהליכים יוצרת אי-תלות בינה לבין השכבות האחרות ומאפשרת גמישות בשינוי התהליכים.

תקינה

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

BPMN

(Business Process Modeling Notation)

סטנדרט של אירגון הסטנדרטים (OMG (Object Management Group העוסק במידול תהליכים. מתאים לתהליכים אנושיים ולתהליכים אוטומטיים. המהדורה העדכנית היא 2.0.

דוגמא גרפית של מידול תהליך באמצעות BPMN

WS-BPEL

WS-BPEL

(Business Process Execution Language)

תקן של  אירגון התקינה (OASIS (Organization for Advancement of Structured Information Standards חלק מקבוצת התקנים של Web Services. התקן עוסק בביצוע תהליכים אוטומטיים בין מערכות ממוחשבות. הוא כולל שפה של הגדרת אלמנטים ושלבים בתהליך. מבוסס על שפות קניניות של Microsoft ושל IBM.

הגדרת התהליך לביצוע נעשית באופן  גרפי ממסך. המהדורה העדכנית (נכון לאמצע שנת 2010) היא  2.0 . הרחבה לתהליכים אנושיים הנקראת BPEL for People  טרם הבשילה לשלב של  Draft. 

אין תאימות מלאה בין מודל שפותח ב BPMN לבין קוד לביצוע שפותח באמצעות WS-BPEL .

בניית תהליך ב- BPL

 

XPDL

((XML Process Definition Language

תקן של אירגון התקנים (WfMC (Workflow Management Coalition עוסק בביצוע תהליכים ובחלקים מהמידול. משתלב באופן מלא עם התקן  BPMN.

מימוש BPM באירגון

סנכרון ה- IT והעסק

יעד עיקרי של מימוש  BPM הוא סנכרון בין הצרכים העסקיים של הארגון לבין מערכות המחשוב   (Business & IT Alignment). כאשר מושג יעד זה, מערכות המחשוב  מהוות גורם הממנף את היכולות העסקיות של הארגון. כאשר אין התאמה כזו, עלולות מערכות המחשוב להוות גורם המעכב את צמיחת העסקים בארגון עסקי או אי מימוש של  יעדי  הארגון בארגון שאינו עסקי.

תועלות BPM

התועלות העיקריות של מימוש BPM באירגון הן:

Visibility (נִרְאוּת)

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

 ·         לא תמיד ברור איזה מערכות משתתפות בתהליך העסקי

 ·         לא תמיד ברור איזה מחלקות ואיזה בעלי תפקידים משתתפים בתהליך

 ·         כאשר מערכת מוצאת מכלל שימוש, פתאום מתברר שתהליכים מפסיקים לעבוד

 ·         לא ברורים התנאים בהם משתנה רצף הפעילויות

 ·         לא תמיד ידוע איזה מידע זורם בזרימת התהליך

מכך נגזרים:

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

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

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

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

שיפור ויעול התהליך העסקי

 ·         התועלת המרכזית של BPM היא בניית תהליכים יעילים ומשופרים. ייצוג ממוחשב של התהליכים מאפשר את שיפורם.

 ·         יצירת שפה אחידה לאורך כל מחזור החיים של תהליכים

חדשנות (Innovation)

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

מימוש BPM באירגון

נדרשת היערכות מקדימה יסודית לפני הכנסת כלי BPM לאירגון:

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

 ·         קיצור זמן מימוש פרויקט BPM חשוב להצלחת הפרויקט יותר מאשר הקטנת עלויות הפרויקט.

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

 ·         יש להימנע מ"איי BPM" באירגון ולבנות תפיסה כוללת של BPM

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

BPM Competence Center

זהו גוף מרכזי בעל ראיה אירגונית כוללת המרכז ידע ומיומנות ב- BPM ומוביל את הכנסת ה- BPM לאירגון. במרכז זה משתתפים אנשים בעלי תפקידים ומיומנויות שונים.  בחלק מהאירגונים מקובל לשלב אותו ביחד עם SOA Competence Center. באירגונים אחרים הוא חלק מגוף מרכזי רחב יותר הנקרא Integration Competence Center ומטפל בכל תחומי האינטגרציה.

אירגונים שאין להם מספיק משאבים להקמת  BPM Competence Center  חייבים להקצות לפחות ארכיטקט אחד  להובלת מימוש BPM באירגון.

 

הרחבות

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

Case Management

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

הרעיון הוא לנהל Cases ולא טכנולוגיות. הניהול מבוסס על תהליכים ועל BPM, אבל משולב בטכנולוגיות ותפיסות משיקות נוספות כגון אירועים  (Events), בינה עסקית ((Business Intelligence, ניהול תוכן (ECM) ו- CRM.

העקרונות המנחים BPM מבוסס Case Management הם:

 ·         ישנם תהליכי אד-הוק המשתפים אנשים (Collaborative)

 ·         התהליכים הם מוכווני אירועים (Event Driven)

 ·         התהליכים גמישים לשינויים ואינם נקבעים מראש

 ·         התהליכים מבוססי תוכן ומבוססי ידע ומבוצעים על ידי עובדי ידע.

BPM חברתי (Social BPM)

הרחבת השימוש ב- BPM גם לשימוש בתפיסות מבוססות Web 2.0 בכלל ועבודה משותפת (Collaboration) באמצעות רשתות חברתיות בפרט.  בתהליכים אנושיים קיים מרכיב לא אוטומטי.

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

BPM במחשוב ענן

כחלק מהמגמה של שימוש במחשוב ענן   (Cloud Computing), נעשה שימוש במחשוב ענן גם עבור BPM. השימוש בענן נעשה לצרכים הבאים בהקשר של BPM:

 ·         תוכנה כשירות (SaaS) למידול וסימולציה של תהליכים

 ·         Deployment בענן בשרת משותף לאירגון ולאירגונים אחרים (Multi Tennant)

 ·         BPU (Business Process Utilities) הרצה בענן של תהליך סטנדרטי אוטומטי ממוחשב כשירות.

מפת"ח ו- BPM

ניתן להשתמש בנוהל מפת"ח עם שינויים מעטים לתמיכה במימוש BPM באירגון.

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

מחזור חיים

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

מחזור חיים של מערכת ה BPM באירגון

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

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

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

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

 ·         ישנה חשיבות גדולה לבחירת התהליך הראשון המיושם באירגון כפרויקט חלוץ (Pilot).

מחזור חיים של תהליך (Process)

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

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

 ·         בשלב האפיון ניתן לעשות שימוש בכלי BPA (Business Process Analysis). באמצעות כלים אלה ניתן לבנות מודל של התהליך.  את שלב האפיון מובילים אנשי עסקים ולא אנשי מחשוב.

 ·         אחד האמצעים  בשלב הבדיקות הוא ביצוע סימולציה של התהליך  לפעמים באמצעות כלי  BPA ממוחשבים.

 ·         ניתן לבצע את שלב הבנייה באופן אוטומטי מתוך התוצרים של כלי  ה- BPA.

 ·         בדומה לתהליך של Reverse Engineering בין קוד למודל בכלי CASE, מאפשרים חלק מהכלים Reverse Engineering מהתהליכים שנבנו ומתבצעים במערכת למודל שנוצר בכלי BPA.

עץ מערכת

 בשימוש בעץ המערכת בפרויקט BPM חשוב לזכור כי:

 ·         פרויקט BPM הוא ברמת האירגון כולו ולא ברמת מערכת.

 ·         ניתן לראות בפרויקט BPM מעין מערכת מוכנה בדומה לפרויקט ERP, אבל במקרה זה מדובר במערכת תשתיתית בתחום התווכה (Middleware) .

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

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

 ·         ל- BPM יש קשר הדוק יותר להיבטים העסקיים מאשר למערכת יישומית רגילה. הקשר ההדוק בא לידי ביטוי גם בביצוע חלק מהמטלות בתחום המחשוב על ידי משתמשים עסקיים או במשותף על ידי מומחי מחשוב ומשתמשים עסקיים. 

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

פרק 1 יעדים

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

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

הסעיף

מהות השינוי

1.1 לקוח / מומחה יישום

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

1.4 הקשר ארגוני / עסקי

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

1.6 ישימות ועלות/תועלת

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

1.7 אופק הזמן

עשוי להיות צורך להתייחס לאופק זמן ארוך יותר

 

פרק 2 יישום, מהות המערכת

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

בהקשר זה  יש לשים לב לנקודות הבאות:

הסעיף

מהות השינוי

2.2.1 משתמשים

ברמת פרויקט BPM אירגוני סעיף זה עשוי לכלול משתמשים עסקיים וגורמים מחוץ לאירגון

2.2.2 מערכות משיקות

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

2.3 תיחום פנימי

מגדיר מערכות המשתתפות בתהליך ומרכיבים בתהליך כמו Sub-Processes   ושירותים (Services)

2.4 ממשק משתמש

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

2.5 תהליכים

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

2.6. טרנזקציות

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

2.8  פרוצדורות בקרה

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

2.19 אבטחת מידע

יש לתת את הדעת להרשאות להפעלת תהליך והרשאות לביצוע פעילויות בתהליך אנושי ולקושי בהגנה על מידע הזורם בתהליך.

יש להתיחס למנגנונים ייעודיים של כלי ה- BPM להגדרת הרשאות למשתמשים וקבוצות בתפיסה של RBAC (Role Based Access Control).

2.22 ממשקים חיצוניים

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

 

פרק 3 טכנולוגיה ותשתית

פרק הטכנולוגיה  אינו עובר שינויים עקרוניים מהותיים.

פרק 4 מימוש

צפויים הדגשים והשינויים הבאים:

הסעיף

מהות השינוי

4.1  גורמים מעורבים

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

4.2 תוכנית עבודה

נדרש סעיף מורחב יחסית

4.3 השתלבות בארגון

נדרשת התייחסות לבעלי תפקידים חדשים המעורבים ב- BPM ולהגדרת הבעלים (Owner)  של התהליך.    

4.8 חוסן ואמינות

תוכנית הבדיקה צריכה להתייחס גם לסימולציה של התהליך.

4.9 תצורות

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

 

פרק 5 עלות, משאבים

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

BPM במפת הידע של מפת"ח

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

התמחויות - מערכות מידע

אפליקציות מוכנות (ERP, CRM)

ניהול תהליכים עסקיים הוא  ללא ספק אחד הנושאים המרכזיים במימוש אפליקציות מוכנות בכלל ומערכות ERP ושרשרת אספקה (Supply Chain Management) בפרט. התפיסה של היצרנים העיקריים בתחום היא ניהול התהליכים באמצעות כלי מובנה בתוך חבילת ה ERP. הכלי מנצל את האחידות בין רכיבים בחבילה בהיבטים של מבנה בסיס הנתונים ומימוש פונקציונאליות.

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

מחסן נתונים DW

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

מערכות ארכיב

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

התמחויות - מערכות תשתית

תשתיות תקשורת

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

נושאים תומכים

שיתוף המשתמש

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

ניהול שינויים

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

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

תיעוד

מימוש BPM עשוי ליצר תיעוד אוטומטי ממוחשב של התהליכים באירגון ובכך לענות על הקושי האינהרנטי הקיים בתיעוד ידני של תהליכים כתוצאה מנראות (Visibility) נמוכה של מחשוב התהליכים שלא באמצעות BPM.

ניהול

SOA ומפת"ח

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

ניהול יחידת המחשוב

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

ניהול איכות

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

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

בחינת איכות תהליך תעשה במספר רמות:

 ·         התאמת התהליך העסקי המיוצג באמצעות כלי BPM לתהליך העסקי המבוצע בפועל באירגון לפני מימוש כלי BPM.

 ·         שלמות המידול והסימולציה של התהליך.

 ·         איכות ביצוע התהליך. לצורך כך ניתן להשתמש בדווחי BAM.

 ·         זמישות (Agility) התהליך. קלות ומהירות שינוי התהליך בהתאם לשינויים עסקיים.

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

מדדים

המרכיב של BAM  הוא בעצם הצגת מדדים באמצעות לוח מחוונים (Dashboard). קביעה נכונה של המדדים או בהקשר הזה KPI (Key Performance Indicators) היא תנאי הכרחי למימוש נכון של BPM.

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

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