קיבלתם מערכת ממפתח אחר? כך מבצעים Audit בלי לשבור אותה

לא כל פרויקט מתחיל ממסך ריק.

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

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

במצב כזה, המשימה הראשונה אינה לפתח פיצ’ר חדש.

המשימה הראשונה היא להבין מה כבר קיים.

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

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

מהו Audit טכנולוגי?

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

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

המטרה היא להבין:

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

Audit טוב מייצר תמונה אמיתית של המצב.

לא רק רשימת בעיות.

למה חשוב לבצע Audit לפני שממשיכים בפיתוח?

מערכת קיימת מכילה הרבה מידע שלא תמיד מופיע בתיעוד.

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

לדוגמה, שינוי סטטוס של הזמנה יכול:

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

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

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

הסימן הראשון לבעיה: אין תיעוד

הרבה מערכות נבנות בלי תיעוד מסודר.

בהתחלה הכול ברור למי שפיתח אותן.

אבל לאחר כמה שנים, כאשר נכנס מפתח חדש, נשארות שאלות:

• מה עושה כל רכיב?
• איפה נמצאות הגדרות חשובות?
• אילו משימות רקע פעילות?
• מי משתמש ב־API?
• אילו תוספים כוללים התאמות?
• מה ניתן לעדכן?
• מה אסור למחוק?
• למה נכתב קוד מסוים?

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

אבל הוא מגדיל את הסיכון בכל שינוי.

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

לא מתחילים באתר הפעיל

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

לפני שמבצעים שינוי צריך לוודא שיש:

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

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

לכן בודקים קודם בסביבה נפרדת.

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

השלב הראשון: להבין מה המערכת עושה עבור העסק

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

אני מתחיל בדרך כלל בשאלות פשוטות:

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

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

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

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

השלב השני: מיפוי הטכנולוגיות

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

במערכת יכולים להיות:

• WordPress
• WooCommerce
• PHP מותאם
• JavaScript
• React או Next.js
• מסד נתונים
• שירותי ענן
• API חיצוניים
• מערכת סליקה
• מערכת חשבוניות
• שירותי דיוור
• WhatsApp
• CRM
• משימות מתוזמנות
• Webhooks
• כלי אוטומציה

המטרה היא לזהות מי אחראי על כל חלק.

לדוגמה:

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

בלי מיפוי כזה קשה להבין היכן מתחילה התקלה.

השלב השלישי: בדיקת הקוד

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

צריך לבדוק גם אם הקוד:

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

קוד יכול לעבוד במשך שנים ועדיין להיות מסוכן לשינוי.

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

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

המטרה אינה לבקר את מי שכתב את המערכת.

המטרה היא להבין את רמת הסיכון ולהחליט איך נכון להמשיך.

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

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

הוא מכיל את המידע של העסק:

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

במהלך Audit בודקים:

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

לא מוחקים מידע רק משום שהוא נראה מיותר.

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

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

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

במערכות WordPress ו־WooCommerce, חלק גדול מההתנהגות מגיע מתוספים.

צריך לבדוק:

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

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

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

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

מערכת מודרנית כמעט אף פעם אינה פועלת לבד.

היא יכולה להיות מחוברת ל:

• מערכת סליקה
• חשבוניות
• CRM
• שירותי משלוחים
• מערכת מלאי
• מערכת דיוור
• WhatsApp
• Google Calendar
• כלי אוטומציה
• מערכות הנהלת חשבונות
• שירותי AI

צריך לבדוק:

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

חיבור חיצוני שאינו מתועד הוא סיכון עסקי.

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

השלב השביעי: בדיקת אבטחה והרשאות

מערכת יכולה לעבוד היטב ועדיין להיות חשופה.

במהלך Audit צריך לבדוק:

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

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

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

השלב השמיני: בדיקת ביצועים

מערכת איטית אינה תמיד מערכת שדורשת בנייה מחדש.

לפעמים המקור הוא רכיב אחד.

בבדיקת הביצועים בוחנים:

• זמן תגובת השרת
• שאילתות למסד הנתונים
• קוד שרץ בכל בקשה
• משימות רקע
• שימוש בזיכרון
• קריאות API
• Cache
• קבצים גדולים
• עומס באזור הניהול
• התנהגות תחת עומס

חשוב לבדוק גם תהליכים אמיתיים.

לא רק את עמוד הבית.

לדוגמה:

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

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

השלב התשיעי: בדיקת תהליכים מתוזמנים

מערכות רבות מריצות פעולות ברקע.

לדוגמה:

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

צריך לבדוק:

• מה מפעיל את המשימה
• באיזו תדירות היא רצה
• כמה זמן היא אורכת
• האם היא נכשלת
• האם היא יכולה לרוץ פעמיים
• האם קיים לוג
• מה קורה אם היא נעצרת

משימה תקועה יכולה ליצור אלפי פעולות ממתינות ולהשפיע על כל המערכת.

איך יודעים במה אסור לגעת?

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

יש קוד שנראה לא יפה, אבל עובד בצורה יציבה.

ייתכן שנכון לתעד אותו ולהשאיר אותו בשלב הראשון.

לא כל רכיב צריך לעבור שכתוב.

החלטה על שינוי צריכה להתבסס על:

• רמת הסיכון
• השפעה עסקית
• עלות התחזוקה
• שכיחות התקלות
• מגבלות עתידיות
• זמן הפיתוח
• יכולת הבדיקה

המטרה היא לא לייצר קוד “מושלם”.

המטרה היא לשפר את המערכת בלי לסכן את העסק.

טעויות נפוצות כשמקבלים מערכת ממפתח אחר

מוחקים רכיב שלא מבינים

רכיב שאינו מוכר לא בהכרח מיותר.

צריך קודם לבדוק היכן הוא נמצא בשימוש.

מעדכנים הכול בבת אחת

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

עדיף לעבוד בשלבים.

מתקנים ישירות באתר הפעיל

כך כל טעות הופכת מיד לבעיה של לקוחות.

כותבים מחדש לפני שמבינים

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

שכתוב מהיר עלול למחוק תהליכים חשובים.

מסתמכים רק על בדיקות אוטומטיות

כלי בדיקה יכולים לזהות בעיות, אבל אינם מבינים את כל התהליך העסקי.

לא בודקים תרחישי קצה

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

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

האם תמיד צריך להחליף את המפתח הקודם?

לא.

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

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

כאשר שיתוף פעולה אפשרי, הוא יכול לקצר מאוד את שלב הבדיקה.

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

העסק צריך להחזיק:

• גישה לקוד
• גישה לשרת
• גישה למסד הנתונים
• חשבונות שירות
• מפתחות API
• גיבויים
• תיעוד בסיסי

המערכת היא נכס של העסק.

הידע עליה צריך להיות נגיש לעסק.

מה מקבלים בסוף Audit?

Audit מקצועי צריך להסתיים במסמך ברור.

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

התוצר צריך לכלול:

תמונת מצב

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

בעיות קריטיות

תקלות או סיכונים שדורשים טיפול מיידי.

בעיות חשובות

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

שיפורים מומלצים

ביצועים, אבטחה, קוד, תהליכים וחוויית משתמש.

סדר עדיפויות

מה מטפלים קודם ומה יכול להמתין.

הערכת היקף

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

תוכנית חזרה לאחור

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

תיקון, שדרוג או בנייה מחדש?

לאחר הבדיקה ניתן לבחור בין שלושה מסלולים.

תיקון נקודתי

מתאים כאשר המערכת יציבה ורוב המבנה תקין.

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

שדרוג הדרגתי

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

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

בנייה מחדש

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

גם במקרה כזה צריך לבצע מעבר מתוכנן.

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

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

תהליך מסודר נראה בדרך כלל כך:

1. יוצרים גיבוי מלא.
2. משכפלים את המערכת לסביבת Staging.
3. מתעדים את המצב הקיים.
4. מבצעים שינוי אחד או קבוצת שינויים קשורה.
5. בודקים את התהליך הטכני והעסקי.
6. בודקים תרחישי שגיאה.
7. מכינים תוכנית חזרה.
8. מעלים בזמן מתאים.
9. מנטרים את המערכת לאחר העלייה.
10. מתעדים את השינוי.

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

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

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

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

במקרים מסוימים נדרש תיקון נקודתי.

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

זו עבודה שדורשת סבלנות.

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

לא תמיד מי שבנה את המערכת טעה.

לפעמים הדרישות השתנו.

העסק גדל.

נוספו משתמשים.

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

המסקנה

כאשר מקבלים מערכת ממפתח אחר, לא מתחילים מהפיצ’ר הבא.

מתחילים בהבנה.

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

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

ב־E.L. Software Solutions אנחנו מבצעים בדיקות, תיקונים והמשך פיתוח של מערכות קיימות — כולל WordPress, WooCommerce, Web Apps, מערכות עסקיות ואינטגרציות.

המטרה אינה לשנות הכול.

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

קיבלתם מערכת קיימת ולא בטוחים מה המצב שלה?

אפשר להתחיל ב־Audit מסודר.

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

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