פלטפורמת מיזוגים ורכישות שנבחרה בצורה גרועה בדרך כלל נכשלת ברגע הגרוע ביותר האפשרי: כאשר חדר העסקאות פעיל, יועצים חיצוניים מבקשים גישה, קבוצות הרשאות מתרבות, ולצוות העסקאות אין עוד זמן לבנות מחדש את התהליך. פלטפורמה שנראתה מספקת במהלך הרכש יכולה להפוך לצוואר בקבוק אם היא לא יכולה להתמודד עם נפח מסמכים, גישה מרובת צדדים, דרישות ביקורת או בקשות תמיכה תחת לחץ עסקי.
זו הסיבה ש"כיצד לבחור פלטפורמות טכנולוגיות למיזוגים ורכישות" הפכה לשאלה של יכולות ולא רק משימת רכש. פיתוח תאגידי, משפטי, פיננסי, IT ויועצים חיצוניים תלויים כולם באותה מערכת במהלך עסקה, אך לעתים רחוקות הם זקוקים לאותם דברים ממנה. תהליך בחירה מובנה מפחית את הסיכון למעבר באמצע עסקה, חרטה לאחר פריסה וחיכוכים תפעוליים שצדדים נגדיים יכולים לראות.
בחירת פלטפורמת מיזוגים ורכישות ראויה למבנה משום שטכנולוגיית העסקה משפיעה ישירות על מהירות הביצוע, הסודיות והשליטה. פלטפורמה חלשה יכולה להאט את תהליך הביצוע, ליצור שגיאות הרשאה, להגדיל את העבודה הידנית ולגרום לקונה או למוכר להיראות לא מוכנים מספיק במהלך תהליך רגיש בזמן.
הלחץ גובר משום שצוותי עסקאות צפויים לפעול מהר יותר תוך כדי ניהול סקירות מורכבות יותר. סקר מגמות מיזוגים ורכישות של דלויט לשנת 2025 מתאר את הסתגלותם של עושי עסקה באמצעות שינויים, תפניות וחדשנות ככל שהפעילות מתאוששת ותנאי העסקה מתפתחים. בסביבה זו, לא ניתן להתייחס לבחירת טכנולוגיה כאל החלטה אדמיניסטרטיבית של הרגע האחרון.
הבעיה המעשית היא שחוזי פלטפורמה ארגונית נמשכים לעתים קרובות ל-12 חודשים או יותר. אם נבחרת מערכת שגויה, הצוות עלול להיתקע בשימושיות ירודה, עודפי שימוש נסתרים, תמיכה מוגבלת או אינטגרציות חסרות זמן רב לאחר סגירת העסקה המקורית. זה הופך את בחירת תוכנת פיתוח ארגונית לתרגיל ניהול סיכונים לא פחות מאשר לתרגיל רכישת פתרונות.
בחירת פלטפורמה טובה מתחילה לפני הדגמות ספקים. צוותי עסקאות צריכים לתעד תחילה את זרימות העבודה שהפלטפורמה חייבת לתמוך בהן: בדיקת נאותות עסקאות, גילוי רגולטורי, דיווחי דירקטוריון, דיווחי LP, תכנון אינטגרציה, הכנת מכירת נכסים או ניהול חוזים שוטף. כל מקרה שימוש יוצר דרישות פונקציונליות שונות.
מסמך דרישות מעשיות צריך להגדיר חמש קטגוריות. ראשית, קריטריוני אבטחה: אישורים, מיקום נתונים, MFA, SSO, הצפנה ודיוק הרשאות. שנית, קבוצות משתמשים: צוותי עסקאות פנימיים, יועצים משפטיים, כספים, רואי חשבון, צדדים נגדיים, מציעים ויועצים חיצוניים. שלישית, הנחות נפח: ספירת מסמכים צפויה, מספר משתמשים, תדירות עסקאות, טעינת שאלות ותשובות וצורכי ארכיון. רביעית, צורכי זרימת עבודה: בקרת גרסאות, אישורים, דיווח, ניתוב שאלות ותשובות וייצוא. חמישית, אינטגרציות: CRM, ניהול מסמכים ארגוני, ERP, ניהול עניינים משפטיים ומערכות זהות.
זהו הבסיס לקריטריונים להערכת פלטפורמת מיזוגים ורכישות. בלעדיו, צוותים משווים טענות ספקים במקום לבדוק האם הפלטפורמה מתאימה למודל התפעול בפועל שלהם.
תהליך הערכה מובנה של ספקים מספק לצוותים דרך עקבית להשוות פלטפורמות באותם תנאים. התהליך הטוב ביותר מתחיל בדרך כלל ברשימה ארוכה המבוססת על כיסוי שוק והתאמת מקרה שימוש, ולאחר מכן מצטמצם לשלושה עד חמישה ספקים לבדיקה מעמיקה יותר.
בשלב זה, צוותים צריכים להשתמש בכרטיס ניקוד משוקלל. לדוגמה, פיתוח תאגידי עשוי לתעדף מהירות וזרימת עבודה של שאלות ותשובות, משפטי עשוי לתעדף מסלולי ביקורת והרשאות, IT עשוי לתעדף אבטחה ואינטגרציות, ופיננסים עשויים להתמקד בעלות הבעלות הכוללת. צוותים המבצעים השוואות ראש בראש, כגון אתר נתונים לעומת חדר עסקי, להשיג תוצאות מעשיות יותר כאשר שתי הפלטפורמות מוערכות על פי אותם קריטריונים משוקללים במקום להעריך אותן ברצף עם שאלות שונות.
הערכה נכונה של ספק טכנולוגיית עסקאות צריכה לכלול גם הדגמה חיה תוך שימוש בסוגי המסמכים והתרחישים של החברה עצמה. הדגמות גנריות שימושיות להתמצאות, אך הן לעיתים רחוקות מראות כיצד הפלטפורמה מטפלת במבני תיקיות מורכבים, קבוצות קונים מוגבלות, העלאות מאוחרות, הסלמה של שאלות ותשובות או דרישות ייצוא תחת לחץ.
עבור פריסות גדולות יותר, פיילוט או הוכחת היתכנות לרוב שווים את המאמץ. בדיקת פלטפורמה עם משתמשים מציאותיים, דוגמאות מסמכים אמיתיות וקבוצות הרשאות אמיתיות מעלה בעיות שקריאות רכש לא חושפות.
צוותי עסקאות מנוסים בדרך כלל שוקלים את הסיכון בביצוע יותר מאשר את ליטוש הממשק. הפלטפורמה חייבת להיות קלה מספיק לשימוש, אך קלות השימוש לבדה אינה מספיקה בעסקה פעילה.
הקריטריון הראשון הוא פירוט ההרשאות. צוותי עסקאות צריכים לשלוט בגישה ברמת סביבת העבודה, התיקייה, המסמך והמשתמש. זה חשוב בתהליכי מכירות פומביות, חלוקות גבולות, ביקורות חוצות גבולות ומצבים שבהם מציעים או יועצים שונים צריכים לראות חומרים שונים.
הקריטריון השני הוא שלמות נתיב הביקורת. כל צפייה, הורדה, העלאה, שינוי הרשאה ופעולת משתמש מהותית צריכים להירשם בפורמט שניתן לייצא לצורך בדיקת תאימות או עסקאות. עבודת בניית היכולות של מקינזי בתחום מיזוגים ורכישות מדגישה ספרי משחק מוסדיים ויכולות חוזרות ונשנות לאורך מחזור חיי העסקה, דבר הרלוונטי מכיוון שיכולת ביקורת ומשמעת תהליכית הן חלק מהפיכת ביצוע מיזוגים ורכישות לחזרה ולא מאולתר. ראו סקירה כללית של מקינזי בנושא בניית יכולות מיזוגים ורכישות.
הקריטריון השלישי הוא זמינות התמיכה. מועדי מיזוגים ורכישות לא תמיד מכבדים את שעות הפעילות הסטנדרטיות. חלונות חתימה, מועדי בדיקות, מחזורי סקירה של הדירקטוריון וגאות שאלות ותשובות של קונים דורשים לעתים קרובות תמיכה מהירה של ספקים.
הקריטריון הרביעי הוא מהירות הקליטה. ייתכן שיהיה צורך לעלות לאוויר במהירות, במיוחד כאשר לוח הזמנים של העסקה מצומצם. פלטפורמה הדורשת תצורה ארוכה יכולה להפוך לאילוץ עוד לפני שבדיקת הפרויקט מתחילה.
הקריטריון החמישי הוא איכות זרימת העבודה של שאלות ותשובות. פלטפורמות חזקות מנתבות שאלות, מקצות בעלים, עוקבות אחר תשובות ושומרות על היסטוריית התקשורת. מערכות חלשות דוחפות דיאלוג עסקי קריטי בחזרה לדוא"ל, שם בקרת הגרסאות והאחריותיות מתדרדרות.
הטעות הנפוצה ביותר היא בחירה המבוססת אך ורק על מחיר. תמחור ראשי לעיתים רחוקות משקף את עלות הבעלות הכוללת. עודפי שימוש, מגבלות אחסון, משתמשים נוספים, תמיכה פרימיום, דמי ארכיון ועבודות אינטגרציה יכולים להפוך את האפשרות הזולה ביותר ליקרה יותר לאחר שהעסקה נכנסה לתוקף.
הטעות השנייה היא לתת לבעל עניין יחיד להיות אחראי על כל ההחלטה. מערכות המידע אולי מבינות אבטחה, רכש אולי מבינות תנאי חוזה ופיננסים אולי מבינות תקציב, אבל פיתוח תאגידי ותפעול משפטי מבינות את תהליך העבודה. בחירת תוכנה לניהול עסקאות ללא המשתמשים היומיומיים יוצרת סיכון אימוץ.
הטעות השלישית היא דילוג על משא ומתן על חוזה לפני הפריסה. מגבלות שימוש, תמחור חידוש, גישה לארכיון, רמות תמיכה, ייצוא נתונים וזכויות יציאה מהמערכת קלות יותר לניהול משא ומתן לפני חתימה מאשר לאחר שהפלטפורמה הופכת קריטית למשימה.
הטעות הרביעית היא התעלמות מ"offboarding". כאשר עסקה נסגרת, צוותים צריכים לייצא, לאחסן בארכיון, להגביל או להעביר חומרים בצורה נקייה. פלטפורמה שקל להשיק אך קשה לצאת ממנה יוצרת סיכון תפעולי לטווח ארוך.
הטעות החמישית היא להתייחס לאופן ניהול תהליך בקשת הצעות מחיר (VDR RFP) כפעילות חד פעמית. ככל שטכנולוגיית העסקאות מתפתחת, ציפיות האבטחה משתנות, ופלטפורמות שעבדו לפני שנתיים עשויות לא להתאים עוד למורכבות העסקאות הנוכחית. צוותים צריכים לבחון ספקים מעת לעת, במיוחד לאחר עסקאות גדולות או כשלים בזרימת עבודה.
בחירת פלטפורמת מיזוגים ורכישות היא החלטה של יכולות, לא של רכישת סחורה. צוותים שמגדירים דרישות בבירור, מערבים את בעלי העניין הנכונים, מעריכים ספקים באופן עקבי ובודקים פלטפורמות בתנאי עסקה מציאותיים, נוטים יותר לבחור כלים התומכים בביצוע במקום להאט אותו. ככל שמורכבות העסקה עולה וצוותי פיתוח תאגידיים מתמודדים עם לחץ להתקדם מהר יותר עם פחות משאבים, איכות תשתית הטכנולוגיה התומכת בתהליך הופכת לגורם ישיר לתוצאות עסקה. הפלטפורמה שנבחרת לפני תחילת העסקה מעצבת את היעילות, האבטחה והשליטה בכל מה שיבוא לאחר מכן.
