פוסטים אחרונים

תגיות

ניווט

ארכיון

BPM, BPR and BPI

I have lately participated in a debate in one of the groups I’m member in, BP Group, on the topic of: What are the fundamental differences between BPM, BPI and BPR.

I love those small little questions that pops up every now and than and make us do some “hmmmm…” and go back to the origin and nature of things …

So, What are the fundamental differences between BPM, BPI and BPR?

Here is my comment and contribution to the debate.

BPM

BPM, Business Process Management, is a Methodology!, and not a technology for integration and/or managing human tasks, and by that it is not a product of one or another vendor, but simply a methodology which evolved from the world of organization and methods (Industrial engineering) and its wisdom are methods, processes, people and the data between them.

“ … the discipline of modeling, automating, managing and optimizing business processes throughout their lifecycle to increase profitability.” Business Process Management: A Practical Guide Rashid N. Khan

So, BPM = A process methodology guidelines for managing processes in order to increase profitability by improving manageability and agility:

Manageability
- Know who does what when and why
- Measurement units
- Transparency
Agility - derived by manageability by
- Understanding your process > understand process boundaries and agility
- Consisted business improvement
- Empowerment

On the other hand BPMS (for Business Process Management Suite/System) is the term for the tools and technology that are target to address and implement the BPM methodology.

A set of software tools that can be used to:
Process Centric Philosophy
“Why” not the “what”
Business Driven
People AND Applications
Align Business and IT and create a mutual process centric language

A typical BPMS will include the following key tools to address these capabilities:

BPA – Business Process Analysis – this is the tool to analyze, model, simulate, document and improve the process. In a modern (3^rd generation) BPMS tools this would typically be the main environment for managing the lifecycle of a process in an organization.

BPE – Business Process Execution/Engine – the run-time environment for executing the processes and automate, maintaining SLA, making sure the process promotes according to its model and business rules etc’. In a modern (3^rd generation) BPMS tool, this engine will be a interpreted runtime engine – meaning the engine will interpreted the process model (xml format) into runtime model on the fly (codeless engine).

BAM – Business Activity Monitoring – this is business monitoring tool which will allow business users and responsible personal to monitor the plan (BPA) versus execution (BPE) at any giving time in the process lifecycle and take active management actions (i.e cancel processes,reassign/delegate tasks, create reworks, rollback etc).

So far for BPM (and BPMS), and now for BPR & BPI.

BPR

BPR, Business Process Reengineering, a strong current from the early nineties which also evolved from the world of organization and methods (Industrial engineering) and was targeted to, as its name implies, Re-Engineer the complete process, or as used to be said and done “starting all over, starting from scratch”. BPR had two main issues:

It targets for big/core change which is hard, expensive and un-agile
It dealt with the general process description (or theoretical process) and many times failed to move to the executable process model

Even today, many times I come to customers who have organization and methods departments and BPR engineers I see a very big gap between the processes as they are modeling it, to the actual model that comes out from the BPM (using the BPA tools as described above) and goes into execution.

Now this has been said, going back to BPM, BPM is an evaluation and expanding of the BPR current, improving the main issues BPR failed like focusing on the execution process model and a creating a culture of an ongoing improvements instead of “Reengineering”.

BPI

BPI, Business Process Intelligence, is the intelligence that comes out of the mining the Business Process data which goes beyond the immediate process KPI and data like workloads, bottlenecks etc’. The challenge here is to mine the intelligence regarding the culture, behavior patterns, methods etc’ which could not have been seen before and otherwise. For sample, let’s take into consideration a very simple and trivial process like vacation request. After a while of running this process, one organization can mine info and see, for sample:

What are the most wanted period for vacations – this can help to foresee and strengthen specific critical teams with external personals or to help adjust number of employee on vacation or may even lead to decide on a collectively company vacation and more
What are the least vacation period – this can be beneficial for the company to create incentive for employee to go on vacations on this times or plan for internal courses etc’
And more…

Once this intelligence has achieved it has a very great potential to make improvement both in the process level and in the enterprise decision making level and improve its overall performance. This is where the other meaning for the I in the BPI comes in – Improvement.

Posted: Jan 19 2009, 10:03 AM by yanivl | with 1 comment(s)

תגים:Agility, תהליכים, BPM, WorkFlow, Empowerment, process, תהליכים עסקיים, ITPRO

SOA Governance - The Need For Speed

Service Orientation, או בקיצור SO, הנה גישה עסקית (ולא טכנולוגית!) אשר מטרתה לאפשר לארגון את גמישות הנדרשת כיום להגבה לאתגרים ושינויים עסקיים, ואמצעיה הנם יצירת סינרגיה ואיזון בין ה Business ל IT מתוך שירותיות הדדית.

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

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

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

ניתן ללמוד על דוגמאות לאתגרים אלו ישירות מתוך ניתוח והבנה של אבני הבניין של SOA, כך לדוגמא:

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

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

עולם ה Governance , מחולק לשני תחומים מרכזיים:

Run Time Governance – המטפל במעקב אחר שירותים בזמן ריצה ובאכיפה של כללי בקרה (Policies) בזמן הריצה שלהם. ה Run Time Governance מורכב מה מהאלמנטים המרכזיים הבאים:
- Operational Governance – מטפל במעקב וניטור שירותים בזמן ריצה לזיהוי עומסים, צווארי בקבוק, זמינות, שגיאות ועוד ובאכיפה של זמני שירות נדרשים דרכי התקשרות, סכמות מידע ועוד.
- Business & Identity access Governance – מטפל בניטור ואכיפה של הרשאות ומקורות גישה בין משתמשים וצרכנים על פי זהות ו/או שיוך עסקי לבין שירותים.
Design Time Governance – מטפל באכיפת כללי בקרה על ארכיטקטורה, ניהול ושימור ידע טכנולוגי, תהליכי הפיתוח, ההטמעה והצריכה של שירותים. תחום זה מורכב משלושה אלמנטים מרכזיים :
- Portfolio Management - מטפל בשלב הקצאת (ושיתוף/איחוד) המשאבים בהיבט של ניהול פרויקטים ופיתוח מבוזר.
- Architecture Governance - יכולת ישום ואכיפה של החוקים והבקרה הארכיטקטונית באמצעות ניהול והפצת הידע הארכיטקטוני אל מרכזי הפיתוח דרך סביבות הפיתוח באמצעות אכיפה של תקנים, סטנדרטים והמדיניות הנגזרת והנדרשת מהארכיטקטורה.
- Software Development Life Cycle Management - מנהל את התהליכים והשלבים אשר עובר הקוד במחזור החיים שלו.

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

בסדרת ה Post-ים הבאה אספק מספר הבנות קצת יותר מעשיות לגבי התחומים המרכזיים של SOA Governance, ה Design Time וה Run Time, באמצעות הקבלה לתחומים שונים בהם "Governance" מבוצע כברירת מחדל ואי ביצועו יהווה פגיעה משמעותית ביכולת התפקוד העסקית עד כדי אי יכולת תפקוד עסקי.

קריאה מהנה :)

Posted: Nov 23 2008, 02:00 AM by yanivl | with no comments

תגים:Agility, SOA, Architecture, Best Practice, ITPRO, TECH, Governance

.NET Architects Coming Meeting - A Journey to SOA Governance

Hi,

In the coming .NET Architect group meeting I have the honor to lecture on highly important and very hot topic - SOA Governance.

If you're an architect, CTO, development/project manager or any of those other that struggles to innovate for new better approaches for development and IT infrastructure and making them aligned with your business - I think you need to free up your calendar and join this meeting.

In the coming days I will be posting few continues blog posts on this subject - stay tuned...

Here is the official .NET architects group meeting invitation.

Please note that you need to register for this group meeting as detailed below.

-----------------------------------------------------------------------------------------------------

Greetings .NET architect!

You are welcome to attend our next meeting to be held on Sunday, November 23^rd at Microsoft in Ra'anana.

This month's topic will be all about SOA governance – a very important topic for any organization that understands software shouldn't behave just as mushrooms after the rain do.

In this lecture we will learn the true business value gained from SOA Governance. We will cover best practices and essential design patterns for SOA Governance based on the Enterprise Integration Patterns (EIP) advanced methodology. We’ll keep practical and have a unique, interesting and creative demonstration of one of the largest SOA based organization's journey to govern more than 200 services.

We will cover:

The need for speed – why govern? When do we know we need to start?
Understanding Service Life Cycle Management (SLM) – the service paradigm
The Iceberg model - Runtime VS Design Time Governance
BSM, Impact Analysis,… - practicable supportive decision tools
Live Demo
And more…

About the presenter:

Yaniv Levi is a senior technical manager and SOA Architect at SRL Group ltd.

Yaniv leads architectural design and concepts of various enterprise level products and projects in the domain of BPM, SOA, Office Business Applications and Mobile Applications.

To register for the event, please email netsa@consiv.com.

Date: November 23^rd, 2008 (23/11/2008)

Time: 17:30 – 20:00

Location: Microsoft Offices – Dekel Conference Room, Hapnina 2, Ra’anana

Topic: To Manage Or Not To Manage – A Journey to SOA Governance

Agenda:

17:15 - 17:30 Assembly
17:30 - 18:30 To Manage Or Not To Manage – A Journey to SOA Governance – Yaniv Levi – SRL.

18:30 - 18:45 Break

18:45 - 19:45 To Manage Or Not To Manage – A Journey to SOA Governance – Yaniv Levi – SRL.

Thank you and see you there!

Posted: Nov 19 2008, 06:16 AM by yanivl | with no comments

תגים:Agility, SOA, Architecture, ITPRO, TECH, DEV

האם אתם מוכנים לצלול עם הכרישים? SRL12 ב TechED 2008

הגיע היום - TechED 2008!

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

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

Technorati Tags: TechEd,TechEdIsrael2008,טק-אד

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

להלן תוכנית המרצים של SRL.

אותי תוכלו לפגוש בהרצאה על SOA Governance שתתקיים ביום שלישי בשעה 11:00, בה אלווה את רועי אגבאבא, סמנכ"ל ב SRL ומנהל חטיבת Professional Services, בהדגמה מעשית לביצוע Design Time Governance של שירותים ורכיבים בעולם SOA.

נתראה באילת :)

Posted: Apr 06 2008, 01:37 PM by yanivl | with no comments

תגים:TechEd, TechEdIsrael2008, טק-אד

Visio for BPM - AgilePoint Envision

הקדמה

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

פתרון זה מהווה פלטפורמה מודרנית מלאה ורחבה (BPMS 3^rd’ Generation) לניהול תהליכים עסקיים, המוכר כ Business Process Management (BPM) ככלל וכפתרון Office Business Application (OBA) בסביבת טכנולוגיות מייקרוסופט ועובדי הידע.

הבעיה והאתגר

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

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

לקשר אנשים מערכות ומידע = יעילות

על מנת

להגדיל את היעילות ויכולת הניהול = פרודוקטיביות

ובד בבד,

לשמור על גמישות לצורך יכולת התאמה לתנאי שוק משתנים = גמישות

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

People Ready Processes

AgielPoinit BPMS עונה לאתגרים אלו באמצעות מה שנקרא: The People Ready Processes כפי המוצג באיור הבא (1) ומוסבר להלן:

חיבור התהליכים השונים (ראה 1.1 באיור): תהליכי רכש (אישור הזמנה, הנפקת חשבוניות, וכו'), תהליכי HR (קליטת עובד, עזיבת עובד, יציאת לחופשה), תהליכי IT (העברה לייצור, הקמת Storage וכו') ותהליכים מתחומים שונים נוספים ומגוונים

לאנשים (ראה 1.2 באיור): עובדי הידע - מנהל מחלקת רכש, אנשי HR ועוד

וקישור בין השניים באמצעות מערכות ומידע דרך כלי היעילות של Microsoft Office וכלים נוספים (ראה 1.3 באיור).

איור 1 – The People Ready Processes

ואיך משיגים את זה דה-פאקטו?:

שימוש ב VISIO ככלי תכנון תהליכים וכלי Office נוספים לצורך ה Runtime ו Front End = יעילות (Efficiency)
בכך אנו משיגים יכולת להעצמת עובדי הידע לניהול התהליכים העסקיים השונים שלהם = גמישות (Agility)
ובסופו של דבר משיגים גם חיבור טוב יותר, או אם תרצו סינרגיה, בין מערך ה IT לעובדי הידע = פרודוקטיביות (Productivity)

הרי בסופו של דבר, אם אנחנו רוצים להעצים את עובדי הידע ולהגביר היעילות, אילו כלים טובים יותר מכלי היעילות של Office?! לא בכדי ל Office ישנם כ 400 מיליון רישיונות והטמעות המשמשים את עובדי ידע ככלי הידע והיעילות העדיפים שלהם!

AgilePoint Envision = Visio For BPM

לצורך ההבנה בואו נראה את איור מספר 2 המציג את ארכיטקטורת העבודה בסביבה מונחית תהליכים המעצימה את עובדי הידע באמצעות ה AgilePoint Envision, הוא ה Visio For BPM:

איור מספר 2 – ארכיטקטורת עבודה Visio For BOM

יש לנו את עובדי הידע מצד אחד (2.1) ומערך ה IT מצד שני (2.2)

ה Envision = Visio For BPM מאפשר למערך ה IT לייצר חשיפה, ויזואליזציה, של נכסי תהליכים כלפי עובדי הידע (2.3), וכך באמצעות החשיפה גראפית המתאימה לשימוש ע"י עובדי הידע של הנכסים הללו (2.4), יכולים עובדי הידע לייצר ולנהל (כלומר, למדל, לנתח, לתעד, לסמלץ ולשפר) את התהליכים העסקיים שבאחריותם ללא תלות ישירה במערך ה IT (2.5).

לאחר שהתהליך הורכב/צויר (2.5), הוא מועבר מה VISIO ישירות לשרת ניהול התהליכים (2.6, מבוסס טכנולוגיית MS .NET) , שוב, ללא צורך בקידוד ומעבר דרך מערך ה IT והפיתוח, ובשלב זה מוכן כבר להרצה ע"י המשתמשים אליהם הוא נחשף (2.7) דרך שולחנות העבודה וסט כלי Office ומייקרוסופט איתם הם עובדים: MOSS, Word, Outlook, CRM ועוד (ראה בהמשך דוגמאות לאינטגרציה עם כלי הידע והיעילות של Office) נוספים.

אינטגרציה עם מוצרי וטכנולוגיות מייקרוסופט

AgilePoint BPMS כולל אינטגרציה מובנית (Out Of the Box) וייחודית עם כמעט כל מוצר וטכנולוגיה של מייקרוסופט.

המשמעות לכך הנה שמוצרים וטכנולוגיות אלו חשופים (ראה 2.4 באיור לעיל) לעובדי הידע אל סביבת ה VISIO לצורך הרכבה ויצירת תהליכים ויישומי Office עסקיים (OBA) כבר מיום ראשון של עבודה (ראה 2.5-2.7 באיור לעיל).

האינטגרציה כוללת אינטגרציה עם רכיבי ה Client כדוגמת סט כלי Office, InfoPath, Outlook ועוד

אינטגרציה עם רכיבי ה Server: MOSS, Forms Server, Excel Services, MSRS ועוד

וממשיך דרך כלי התשתיות MSSQL, BizTalk ועד רמת הטכנולוגיות לרבות אלו העדכניות ביותר כדוגמת WF, WCF ועוד.

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

מייקרוסופט Visio
מייקרוסופט InfoPath לרבות Forms Server
שרת יישומי Office – MOSS/SharePoint
יישומי Office – Outlook, Word, Excel, PowerPoint…
סביבת הפיתוח Visual Studio .NET
שרת תשתיות אינטגרציה וחיבוריות BizTalk Server
מסדי הנתונים SQL Server
ועוד...

וכמו תמיד, טובה תמונה אחת מאלף מילים

Visio for BPM – Connecting the Business & IT

איור 3.1 מציג שוב את ה AgilePoint Envision הוא ה Visio For BPM המאפשר לעובדי הידע להרכיב תהליכים מקצה אל הקצה באמצעות סביבה גראפית, ידידותית ומונחיה תהליכים המבוססת על ה Microsoft Visio.

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

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

איור 3 - Visio For BPM – Connecting the Business & IT

אינטגרציה עם סביבת שולחן העבודה השיתופי – MOSS/SharePoint

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

איור 4 – אינטגרציה עם MOSS/SharePoint

אינטגרציה עם InfoPath ו Forms Server

איור 5 מציג את השילוב עם רכיב הטפסים של סביבת ה Office תחת שתי האפשרויות הקיימות - לסביבת רכיבי הקצה InfoPath Client (5.2) ו לסביבת ה Web ה Forms Server (5.1).

טפסי ה InfoPath יכולים לשמש כטופס המסתובב ("מתגלגל") בתהליך וככלי לאיסוף מידע כללי עבור התהליך ועוד...

איור 5 – אינטגרציה עם רכיב הטפסים InfoPath.

אינטגרציה עם סביבת ניהול הזמן, אנשים והודעות – Outlook

איור 6 מציג את האינטגרציה עם סביבת ניהול הזמן, אנשים והודעות – ה Microsoft Outlook.

תחת האינטגרציה עם סביבה זו, יכולים המשתמשים לקבל את רשימת המטלות שלהם (ה "Task List") ישירות כמטלות ב Outlook (Outlook Tasks/To-Do List – 6.1, 6.2) ו/או כמיילים ובאמצעותם לקבל את כל המידע הנדרש אודות המשימה ו/או התהליך, לרבות תרשים מעקב ויזואלי (6.3), ואף לבצעם.

איור 6 – אינטגרציה עם Outlook

אינטגרציה עם סביבת ה Office

איור 7 מציג את האינטגרציה הקיימת עם סביבת ה Microsoft Office – Word, Excel, PowerPoint.

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

7.2 – אילו תהליכים זמינים עבורי על מנת לצרף למסמך ולצורך התנעת התהליך והחלת סבב האישורים

7.3 – מעקב ויזואלי אחר התהליך המשויך כבר למסמך

7.4 – היסטוריית מעקב משימות למסמך במסגרת התהליך

ועוד...

לסיכום

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

היכולות המובנות להשתלבות ואינטגרציה עם כלי ה Office בפרט ועם מוצרי וטכנולוגיות מייקרוסופט ואחרים נוספים בכלל, מאפשרת לייצר תהליכים כבר מיום ראשון של עבודה ולהביא תוצאות באופן מיידי – Start small, think BIG, Scale F a s t.

Envision =Enable the Visio Vision

החזון כבר כאן - Start small, think BIG, Scale F a s t

הורד את המאמר.

Posted: Jan 31 2008, 03:47 PM by yanivl | with no comments |

תגים:Agility, תהליכים, BPM, WorkFlow, Empowerment, process, תהליכים עסקיים, Information Workers, OBA, Visio

קצת טקטיקה, קצת אסטרטגיה וקרטוב של פלפל - המתכון לתמהיל מיצוב פתרון

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

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

חסכון - הפתרון מיצר לארגון חסכון ובכך משפר את עלויות התפעול > טקטי
ייצור - הפתרון מייצר/משרת יכולת ייצור חדשה > אסטגטגי

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

תמהיל מיצוב פתרון – המטרה הנה לייצר מאפיינים למיצוב, מיקוד וניהול הפתרון. תמהיל המיצוב צריך לכלול בין היתר:

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

Posted: Jan 10 2008, 03:46 PM by yanivl | with no comments |

תגים:ניהול, שיווק

Auto-Increment for InfoPath repeating tables/sections

When creating a InfoPath forms to collect business application data, it is often required to use an auto-increment (auto indexing) behavior for auto numbering different data in the form. This is a very common and useful when implementing a repeating table and/or repeating section in order to index the rows in the repeating table or the repeating sections, correspondingly.

In the following post I'll demonstrate three available options to archive this behavior without writing a single line of code!

This options are available and support by both, InfoPath 2003 and InfoPath 2007.

This post has a sample InfoPath form template - DOWNLOAD THE SAMPLE (Auto_Increment_Sample.zip).

Option 1 - Use an Expression Box with the XPath set to position()
This option is great if all you want to do is show the row number. But if you actually want to store the sequential auto-increment numbering in a field, this is not a good option since Expression Box cannot update and save its data to fields in the form. See option 1 in the attached Auto_Increment_Sample.xsn

Option 2 - Use count() of preceding-sibling

To store the auto-number in the forms field, i.e Index_Count field in our form, use the following XPath formula as the default value of the Index_Count field: count(../preceding-sibling::*/my:Index_Count) + 1 and uncheck the update this value when the result of this formula is recalculated.

This XPath actually counts (count() function) the number of nodes in the same level above the current node (preceding-sibling statement).

This will do the work, but if we need the generated Index_Count to assure unique across the table rows, than this will not be enough, since it in case you delete a row and then insert another row, than will have two rows with the same Row_ID value.

See option 2 in the attached Auto_Increment_Sample.xsn

Option 3 - Use InfoPath Rule to create a counter mechanism

In this option we'll use an InfoPath Rule on the index field. This rule will use as a counter mechanism to increment a counter filed as follow:

1. A field to store the item count has been added - Item_Count (/my:myFields/my:Item_Count), with a default value of 1. This field will act as a global variable to the form instance and will hold the latest generated Index_Counter_Rule.
2. The value of the above Item_Count field has been set as the default value of the Index_Counter_Rule field (again, we uncheck the update this value when the result of this formula is recalculate).

3. A rule named “Set_Item_Count” has been added to the Index_Counter_Rule field. This rule is will set the value of Item_Count to (Item_Count + 1). This rule is being triggered after the content of the field is being changed. When we add a new row, the content of this field is being changed due to the default value settings.

See option 3 in the attached Auto_Increment_Sample.xsn

Use the options above as you find best fit to your needs.

Enjoy :)

Posted: Jan 09 2008, 12:02 PM by yanivl | with 23 comment(s) |

תגים:Office Business Applications, Best Practice, InfoPath, OBA

Use of Emails within Workflow and Business Processes

Using emails in a process can be very useful as a notification mechanism in order to notify the process participants and interest on different events in the process instance lifecycle. Most common usage of emails in a process will include notifying users on a new task for its reference. Neither the less, this ease of use and the initial impression of the simplification emails can add to process interaction, it is sometimes can cause the opposite implication.

Here are some issues to take into considerations when thinking of using emails inside process:

Do not overload the user with emails

Take into consideration that the process is not the only system sending the user emails. In some point, if the user will get to much emails for the process, he will become apathetic to those email by not reading them and missing some important information embed into them and in some cases even creating rules in his email client to automatically delete this emails.

Here is a small fact on emails:
According to the Radicati Group, a technology market research firm, the average corporate email user sends and receives more than 16 MB of data per day, a figure expected to rise to more than 21 MB by the end of the decade!

User reference to email are not controlled

A significant luck of using emails is that you have no control on when the user will refer to it. This contradicts the process and task which are dynamic and keeps evolving. In some cases, like parallel tasks, expiration of tasks etc’, the information embed in the email regarding the task and/or process will be completed/canceled or generally irrelevant by the time the user will refer the email.

When to use emails

To notify on general process events: Process Initiation, Process cancellation, Process completion
To notify on tasks: reassign a task, cancel task, new task (see also when not to use)
To notify on SLA – reminding before task expiration

When NOT to use emails

Do not use emails to notify on task when the process is a of the core user working systems, or if they use it more then 50% of their day work time – i.e. if the process is an HR employee reception process, users of the HR department in-charge of the Employee receptions will likely to use this process system as there main work system (see tip at the end of this post)
Do not use emails to notify on new tasks (incoming email notification) if user is target to get more then 1 task per day.

How to use emails

When using email include as much informative details on the task and/or process in order to help the user optimize his work but not to much information so that the email will not be an overload. Information should include: Task name, task due date, process instance name, link to other relative information/resources like TaskList, Help Files, Reports etc’
Format all your email in the same format to allow users to more easily find the info required. In addition, consider using a simple report look and feel like (2 column table: subject and details) formatting to allow users to easily read and locate information. See sample screen shot.
Keep in mind that most user do not read the entire email – make sure to put the most important information in the subject filled and in the first 3 lines of the email.
Make sure to use a safe format and information in your emails so that they will not be blocked by the email server/client and that they will not overload your network bandwidth - some email servers (i.e exchnge) and clients (i.e outlook etc’) may be configured to forbid special email formats, like rich text, HTML etc’, and contents like embedding images, and attachment formats.
Use of “High” (“!”) email flag only when truly necessary – otherwise, users will learn it is overused and will not treat the email as high important (avoid "the boy who shout wolf" effect)
Do not use short lifecycle information inside the email. For sample, do not use a direct link to the task form if the task can be completed by more then one user or can be removed by SLA escalation mechanism.
As much as possible – use expiration date for the email information and make sure they are highlighted.
Add a "Do not reply" note in your emails :)

For the ongoing interactions of users with there tasks and processes, consider not using emails at all and train your users to use their process and or tasks work environment instead (i.e the TaskList, SharePoint etc’). Keep in mind that many of the more common workflow and BPM systems where targeted to exchange the onslaught use of email in the process and tasks lifecycle.

Posted: Jan 01 2008, 04:18 PM by yanivl | with no comments |

תגים:תהליכים, BPM, process, תהליכים עסקיים, Information Workers, WF, Email

Welcome to BlogPM ;)

With today competitive business reality, managing your business processes requires a good skipper skills: know your ship, know and empower your crew member, sharp awareness to wind, curves and waves and a clear yet dynamic strategy to find the exact balance between them in order to, safely and efficiently, get to your destiny.

AHOI – Land ahead!

Posted: Dec 24 2007, 12:26 AM by yanivl | with 1 comment(s) |

תגים:Agility, BPM, WorkFlow, Information Workers, Architecture

?רבולוציה או אבולוציה - BPM

אם אתם ב"תעשייה", בטח ניתקלתם במונח BPM!

כן, BPM הוא ללא ספק ה BUZZ התורן - ממחזור הגיוס של SOA, Governance ועוד כמה...

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

או בקיצור BUUZZZZZZZZZ.......

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

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

לצורך כך, אתחיל בהתחלה:

מהו BPM

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

לצורך ההמשך, נגדיר את המונחים הבאים:

BPM – מתודולוגיה לניהול תהליכים עסקיים כפי שהוסבר לעיל

BPMS – סוויטה של כלים טכנולוגים אשר מיועדים לסייע במימוש מתודולוגיית ה BPM

המטרה

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

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

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

מדוע נדרש BPM

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

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

הבלבול מ BPM

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

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

בלבול זה יצר שתי גישות מרכזיות לעולם ה BPM

גישה ממוקדת אינטגרציה
גישה ממוקדת אנשים וניהול

גישה ממוקדת אינטגרציה

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

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

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

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

גישה ממוקדת אנשים וניהול

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

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

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

למימוש גישה זו נדרשים כלים המאפשרים אוסף היכולות המרכזיים מכלי BPM, מה שמוכר היום כ BPMS – BPM Suite:

BPA – Business Process Analysis: כלים לתיעוד, מידול ותכנון התהליכים.
BPE – Business Process Execution: כלים למיכון, אוטומציה והרצת התהליכים בפועל.
BAM – Business Activity Monitoring: כלים לניטור, ניתוח וניהול תהליכים ומשימות.

מאפיינים ויכולות מרכזיות של כלים אלו בהיבט גישה זו:

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

SOA ו BPM

גם כאן קיים הרבה בלבול, מסוג הבלבול של מה קודם למה, הביצה או התרנגולת?

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

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

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

מסקנה זו הנה כמובן מותנית ומשתנה בהתאם לגישת המיקוד למימוש BPM, גישה ממוקדת אינטגרציה/ממוקדת ניהול ואנשים, כמו גם במגבלות הטכנולוגיות של כלי ה BPMS השונים.

סוגי תהליכים.

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

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

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

עתה נשאלת השאלה, האם התהליך הנו תהליך עסקי?

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

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

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

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

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

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

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

איור 1 - קוביית תהליכים - יכולת מימוש סוגי תהליכים על פי גישות מיקוד

הערכים מ BPM

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

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

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

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

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

גורם	מוטיבציה	תועלת וערכים מוספים
מפתחים ומערך ה IT	טכנולוגיה – תשתית פיתוח, תחזוקה, סטנדרטיות ופתיחות	תשתית פיתוח לתהליכים, אוטומציה ומיכון פיתוח מובנה שכבות – הפרדה בין המערכת (UI, DAL, Integration...) לשכבת התהליך והוצאת כל הלוגיקה העסקית של זרימת התהליך: תנאים, משתתפים, משימות, התפצלויות וכו', החוצה. פיתוח ממוקד לשימוש חוזר ברכיבים מינוף ידע, השקעות וטכנולוגיות קיימות תאימות לסטנדרטים ופתיחות להרחבות ומערכות חיצוניות פיתוח מכוון Agile Development, פיתוח הנו לרכיבי תהליך ממוקדים ורזים - איטרציות קטנות, תוך ויזואליזציה ועבודה צמודה אל הלקוח מאיץ ל SOA ו Composite Applications Development
עובדי הידע – LOB	פתרונות עסקיים, ניהול, גמישות	העצמת עובדי הידע (LOB) והחזרת השליטה בתהליכים העסקיים אליהם שקיפות של התהליכים והמשימות של העובדים זיהוי משימות ופעולות בהם האנשים אינם תורמים ומסייעים ואשר ניתן למכן אותם כלי שליטה וניהול שוטפים ואד-הוק על התהליכים והמשימות
ארגון	סינרגיה עסקית, עמידה ביעדים, יתרון תחרותי	חיבור ויצירת סינרגיה בין עובדי הידע (LOB) לאנשי מערכות המידע (IT) מחד, תוך הפרדה בתהליכים ותלות העבודה מגיסא יישור והכוונת מערכות המידע אל התהליכים העסקיים שקיפות לגבי תהליכים, משימות ויכולות הארגון ומשאביו תיעוד מידע של פעולות ואישורים לצורכי רגולציות מידע מתמיד לזיהוי, תהליכי עבודה, עומסים, צווארי בקבוק ומגמות לשיפור כלים ותפיסה המנחה לבחינה ושיפור מתמיד של תהליכי העבודה

סיכום

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

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

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

Posted: Dec 24 2007, 12:19 AM by yanivl | with 3 comment(s) |

תגים:Agility, תהליכים, BPM, SOA, WorkFlow, Empowerment, process, תהליכים עסקיים, Information Workers, WF, Architecture

Yaniv Levi