שיעור מס' 1

מערכות מידע מורכבות מחומרה (hardware), תוכנה (software), נתונים ומידע (data), מסמכי מקור (input), נהלים (procedures) ומשתמשים (users).

[ההבדל בין נתון למידע הוא שהמידע הוא לאחר שהנתון עובד]

ההיררכיה של מערכת המידע

מערכת

מודול - חלק במערכת שמטפל בנושא מסוים. בד"כ מורכב ממספר יישומים.

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

תוכניות מחשב - מספר תוכניות מחשב מהוות יישום – כתיבת קוד ע"י תוכניתן לשם

ביצוע פעולה מוגדרת.

התפתחות היסטורית של ממ"מ בארגונים

לפני שנות ה- 50 היו אמצעים ידניים בלבד.

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

שנות ה- 60 – מחשבים מדור שני – מהפיכת הטרנזיסטורים, כאשר העיבוד הוא עיבוד אצווה

(batch) (ההיפך מ- online).

שנות ה- 70 – מסופים.

שנות ה- 80 – עיבוד מקוון – online וחדירה של המחשבים האישיים.

שנות ה-90 – פריצת דרך בתחום התקשורת.

המאה ה- 21 – התפתחות האינטרנט ותקשורת בין מחשבים.

גישות לעיבוד נתונים

1. עיבוד אצווה batch – יצירת הקלט מתבעת בנפרד מהזנתו.

דוגמא – משיכת כסף מהכספומט – כאשר מושכים דף מידע מייד אחרי המשיכה לא ניתן לראות את היתרה המעודכנת (כולל המשיכה הנוכחית).

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

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

2. עיבוד מקוון online – יצירת הקלט מתבצעת במקביל להזנתו.

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

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

ארכיטקטורה של מערכות המידע

1. מבנה ריכוזי – מחשב מרכזי mainframe – מחשב המחובר למסופים (טרמינל). כל העיבודים מתבצעים במחשב המרכזי בלבד. כל ההזנות הן במחשב המרכזי.

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

חסרונות

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

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

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

ד. ריכוזיות של ניהול השירות והתחזוקה של המערכת.

יתרונות

א. הנתונים נמצאים במאגר מידע אחד אמיתי עדכני וזמין.

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

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

2. מבנה מבוזר – תחנות עבודה עצמאיות המחוברות ברשת תקשורת מקומית LAN (local area network) ו/או רשת תקשורת ארצית רחבה WAN (wide area network).

מבנה LAN – בנוסף לתחנות העבודה קיימים ברשת המחשב מספר מחשבים המנהלים את המרכיבים השונים של הרשת:

א. שרת התקשורת (network / communication / file server)

ב. שרת היישומים (application server) – מאפשר לכל המסופים/תחנות העבודה להפעיל יישומים שונים כמו word, excel וכו'.

ג. שרת בסיסי הנתונים (database server) – מאפשר לכל המסופים לקרוא נתונים פשוטים (מדדים, שע"ח). הכוונה היא לא למאגר מידע שניתן להזין אליו מידע חדש אלא שרת שמאפשר לכל המסופים לעיין במידע בלבד.

יתרונות

א. אי תלות בין מרכז הארגון לבין הסניפים.

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

ג. קיימת חלוקה מסודרת בין חלקי המידע בארגון.

חסרונות

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

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

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

קן – BUS – הנפוץ ביותר (משרדי רו"ח).

יהלום – כל משתמש מחובר מראש למשתמש אחר (מרכזיות מרחביות בבזק). לא נפוץ משום שהוא יקר ולא משתלם.

טבעת – RING

כוכב – כל המידע מתרכז במרכז או שלמשתמש המרכזי יש אפשרות לפנות לכל אחת

מהתחנות.

WAN

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

השכבות השונות של התוכנה

· השכבה התחתונה היא מערכת ההפעלה – operating system.

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

· תקשורת – התחברות לאינטרנט.

· בסיסי הנתונים – נתוני תשתית data base.

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

יש לציין שלפני מערכת ההפעלה יש חומרה.

המבנה הפנימי של מערכת ההפעלה –

הבסיס – חומרה.

שכבה שניה – מערכת הקבצים – הקוד, התוכניות של מערכת ההפעלה, הגדרות וקבצי bat, exe – תוכניות עזר.

סביבות טכנולוגיות

א. דואר אלקטרוני – אסטרטגיה לפיה הדואר מועבר לארגון/בארגון באמצעים אלקטרוניים.

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

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

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

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

ד. EFT – העברות כספיות בין מוסדות פיננסיים.

שיעור מס' 2

רשת תקשורת מקומית (LAN)– קבוצה של משתמשים שעובדת במקום פיסי אחד.

רשת תקשורת רחבה (WAN) – רישות של ארגון מסוים בעל פריסה גיאוגרפית. בד"כ בכל מחוז/אשכול של רשת תקשורת רחבה קיימת רשת תקשורת מקומית.

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

מחשב בנוי מחומרה (שכבת בסיס) ומתוכנה. התוכנה מחולקת לשכבות –

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

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

· בסיס נתונים – מטרתו לשאוב נתונים מסוימים ולהציב אותם בשכבה אחרת.

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

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

התפתחות ביקורת מערכות מידע ממחושבות

EDP - ענ"א – עיבוד נתונים אלקטרוני. הדגש היה על עיבוד מידע בלבד.

IS – מערכת מידע.

ביקורת ממ"מ כוללת:

1. ביקורת (audit) – בדיקת דברים לאחר מעשה.

2. בקרה (control) – אמצעי בקרות שמובנים בתוך המערכות. מטרתם למנוע דברים בלתי רצויים.

IT – טכנולוגיות מידע.

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

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

קיימות שתי קבוצות של צרכנים:

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

הבעיות שרו"ח נתקל בהן כאשר הוא מגיע לבצע ביקורת –

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

מערכת מידע

פלט סופי (דוחות) נתוני מקור

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

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

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

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

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

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

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

כיום משקיעים משאבים עצומים במחשוב – 5% - 10% מעלויות הכוללות של החברה הן עלויות המחשוב.

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

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

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

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

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

· חומרה

· בדיקה ספציפית של היישומים

· יעילות ואפקטיביות של המערכת

· אבטחת מידע

· מבנה ארגוני

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

ישנן מס' בעיות המאפיינות את סביבת מערכות המידע הממוחשבות:

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

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

3. שגיאות שחוזרות על עצמן.

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

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

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

7. חוסר היכולת להגיב בצורה מהירה.

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

1. תלוי באמינות נתוני המערכת.

2. אפשרויות המעקב מוגבלות (מבחינת נתיב ביקורת, תנועות שנוצרות באופן אוטומטי).

3. חתימות והרשאות.

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

5. העברת מידע בין מערכות מחשב, באותו ארגון או בין ארגונים.

עד שנת 1996 ניסו רו"ח לחשוב כיצד להתמודד עם הבעיה –

1. אסטרטגיית ביקורת מסביב למחשב – ניתן להשתמש באסטרטגיה זו בהתקיים התנאים המצטברים הבאים:

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

הלוגיקה של הרישום זהה ללוגיקה של הרישום הידני.

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

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

[גם כאשר עובדים ע"פ אסטרטגיה זו – עדיין מחויבים לבדוק שהמערכת תקינה]

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

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

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

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

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

גילוי דעת 66

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

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

סעיף 1 בגילוי הדעת מתאר את מטרת גילוי הדעת - להנחות את רו"ח כיצד ליישם את תקנים 5 (מיומנות), 8 (תכנון ופיקוח), 9 (סקר בקרה פנימית) ו- 10 (ניירות עבודה) בביקורת מערכות מידע ממוחשבות – אותם התקנים המושפעים מסביבת מערכות מידע ממוחשבות.

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

סעיף 3 – מטרות הביקורת והיקפה אינן משתנות... במילה "היקף הביקורת" אין הכוונה לנהלי הביקורת אלא לכך שמטרת הביקורת אינה משתנה.

הנהלים עשויים להשתנות, על סיכוני הביקורת (DR * CR * IR) = AR וכן על תכנון הביקורת.

סעיף 4 – אסטרטגית ביקורת מסביב למחשב.

סעיף 5 – מזכיר את תקן 5ביקורת ותקן ביקורת 8.

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

סעיף 8 – מזכירים את הוראות תקן ביקורת 8.

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

[יש לציין שמדובר רק באיסוף מידע על סביבת החברה]

סעיף 10 – לאחר איסוף המידע יש לתכנן את הביקורת. התכנון עלול להיות מושפע מהמידע שנאסף לגבי מערכת המידע של החברה.

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

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

סעיף קטן 2 קובע כי יש להבין את המבנה הארגוני של פעילות הממ"מ.

סעיף קטן 3 – זמינות נתונים.

סעיף 11 – מזכיר את תקן ביקורת 9. בנוסף על רו"ח לקחת בחשבון בעריכת הסקר את נושא המערכות הממוחשבות.

סעיף 13 – חלוקה של מסורתית לבקרות -

בקרות

ידניים ממוחשבים

כלליות יישום

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

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

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

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

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

CAAT – Computer Assisted Audit Techniques טכניקות ביקורת באמצעות מחשב. נבצע בדיקות אלו כאשר אין אסמכתאות בכתב, תנועות שמבוצעות אוטומטית, אין פלט חזותי וכו'.

נספח ב' – סביבת מחשבים אישיים – סביבה נגישה ונפוצה אך פחות מסודרת ממחשב מרכזי.

נספח ג' – סביבת מחשבים on line.

נספח ד' – בסיסי נתונים.

נספח ה' – טכניקות ביקורת באמצעות מחשב.

נספח ו' – לקט מונחים.

נספח ז' – מתוכנן לצאת בשנה הבאה – אינטרנט ומסחר אלקטרוני.

שיעור מס' 3

מתרגל: ערן אוסטפלד

טל': 596873 – 054, 5118259 – 03

מערכות פיננסיות

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

ספר ראשי – מערכת הנה"ח בחברה – דיווחים כספיים/חשבונאיים כלליים.

ספר עזר ספקים

ספר ראשי ספר עזר מלאי

ספר עזר מכירות

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

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

בספר הראשי שני קבצים עיקריים:

1. קובץ תנועות – בו מפורטות כל התנועות (פקודות יומן) בין החשבונות.

קובץ התנועות חייב להסתכם לאפס.

2. קובץ יתרות – בו מפורטות היתרות הסופיות של הסעיפים השונים במאזן.

לכל סעיף בדוח הכספי קיים מספר מייצג.

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

[ממשק – העברת נתונים]

רו"ח חותם על הנתונים שבספר הראשי.

מאפיינים של מערכות מידע פיננסיות – ספר ראשי:

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

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

2. רב מטבעית – חברות שונות מדווחות במט"ח (בכפוף לתנאים לדיווח במט"ח). ניתן לדרוש מאזן בוחן עפ"י מטבעות שונים.

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

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

מעגל מכירות

הצעה ללקוח – מנהלי המכירות מציעים הצעות ללקוחות במטרה לקדם מכירות. ההצעות שנשלחו ללקוחות ממתינות לאישור (ע"י הלקוח).

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

תעודת ההזמנה מוזנת לספר עזר מכירות ומחכה לאישור.

[לא כל לקוח ששלח תעודת הזמנה מקבל אישור – לעיתים בעל חוב כלפי החברה למשל]

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

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

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

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

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

בסופו של התהליך – מסירת המלאי (תעודת המשלוח חוזרת אל החברה חתומה על ידי הלקוח).

במסירת המלאי נרשמת "גריעה" בספר המלאי ובספר הראשי נרשמת פקודת היומן –

ח' עלות מכר

ז' מלאי

הפקת חשבונית – הרגע בו מכירים בהכנסה (בד"כ שולחים את החשבונית יחד עם משלוח הסחורה). הפקת החשבונית נעשית בספר המכירות ומתווסף למאגר החשבוניות.

השפעה על הספר הראשי – רישום פקודת היומן - ח' לקוח

ז' מכירות

ז' מע"מ עסקאות

כאשר מתקבל התקבול מהלקוח – צ'ק, אשראי וכו'. נרשום את התקבול בספר המכירות ונפיק קבלה (לאחר שבדקנו כי התקבול תואם את הסכום שבחשבונית וכו').

בספר הראשי נרשום – ח' מזומן/בנק

ז' לקוח

מערכות נוספות שמושפעות – ספר קופה, גזברות.

מאגרי מידע

1. מאגר מידע לקוחות – מס' לקוח (שדה מפתח - מס' הזיהוי), פרטי לקוח, קו אשראי, תנאי תשלום.

2. מלאי – מס' פריט, תיאור, משקל/יחידות מוצר, ערך

3. הזמנות – מס' הזמנה, תאריך, מס' לקוח, אישר מכירות, תנאי תשלום, כתובת למשלוח.

4. תעודות משלוח – מס' תעודה, תאריך, מס' הזמנה, כמות.

5. חשבוניות – מס' חשבונית, תאריך, מס' לקוח, סכום, תעודת משלוח.

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

מעגל הרכש

[רכוש קבוע, מלאי וכו']

התחלת התהליך – דרישת רכש (PR) – מערכת לוגיסטית המנהלת את מערך הרכש, הייצור, השינוע והאספקה.

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

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

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

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

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

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

בספר המלאי נרשמת תנועת כניסה למחסן. במערכת הלוגיסטית נסגרת ההזמנה. בספר הראשי נראה השפעה – ח' מלאי/רכוש קבוע

ז' ספקים

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

בספר הראשי נרשמת הפקודה – ח' ספקים במעבר

ח' מע"מ תשומות

ז' ספקים

תשלום – ספר ספקים – אירוע תשלום (בסיום תקופת האשראי).

בספר הראשי נרשמת הפקודה – ח' ספקים

ז' בנק/ מזומן

ז' ניכוי במקור

מערכות נוספות שמושפעות – ספק קופה, תקציב.

מאגרי מידע

1. מאגר מידע ספקים – מס' ספק, פרטים, ניכוי במקור וכו'.

2. דרישות רכש – מס' דרישה, תאריך, מזמין, מאשר, כמות, מק"ט.

3. הזמנות – מס' הזמנה, תאריך, ספק, סכום.

4. כניסות מלאי – מס' תעודת כניסה, תאריך כניסה, ספק, מס' הזמנה.

5. תשלומים – מס' צ'ק/העברה בנקאית, בנק, סכום, תאריך, ספק, חשבונית וכו'.

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

שינויים בהון למשל – אין בגינם ספרי עזר ולכן נעשות פעולות ישירות בספר הראשי (ע"י אנשים בעלי הרשאה לבצע פעולות מסוימות בהון).

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

שאלה ממבחן (שאלה 4 במבחן מועצה – חורף 95) – חברת "השיווק הישיר"

החברה מוכרת מוצרים שונים באמצעות סוכנים –

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

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

הסוכנים מעבירים לחברה את ההזמנות השונות ואת החיובים (אל המחשב המרכזי).

לקוח

לקוח

רשת

מקומית קשר טלפוני

הזמנות

חברת השיווק הישיר

חיובים

סליקה

ספקים

חברת אשראי

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

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

קיימים ממשקים בין החברה לספקים.

הוחלט להחליף את מערכת המחשב.

החל משנת 95 פועלת בחברה מערכת מחשב חדשה – התבצעו מבחני הרצה ו"הסבה במקביל" לעבודה במערכת הישנה.

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

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

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

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

3. בחודש 2/95 התברר שקיימות יתרות חובה רבות לא ממויינות – במערכת הישנה הייתה יתרת חוב וניתן היה לייחס אותה ללקוחות מסוימים. במערכת החדשה הועברה היתרה בסכום אחד ולא ניתן היה לדעת למי שייכים הסכומים המרכיבים את אותו החוב.

נדרש א' –

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

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

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

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

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

נדרש ב' –

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

נשאלת השאלה – אילו בקרות נדרשות על מנת לשלוט על תהליך ההסבה.

בקרות במערכת הישנה –

בקרות חתך

1. איסור רישום תנועות מכירה לאחר ה- 31/12/94.

2. רישום תנועת החזרה ב- 95 תתבצע במערכת הישנה רק אם נרשמה עבור אותו מוצר מכירה ב- 94.

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

3. רישום תנועות כספיות במערכת הישנה רק אם הן עבור מכירות שבוצעו ב- 94.

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

5. לקוח שחובו מתאפס במערכת הישנה – חשבונו ייחסם (יותר לא ניתן יהיה להזין פקודות בחשבונו).

בקרות שלמות וחתך

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

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

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

נדרש ג' –

לאור הבאגים שהתגלו (בעיקר בסעיף ב'), האם יש צורך בשינוי היקף הביקורת.

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

סעיפים 18-20 בגל"ד 66 –

סעיף 18 מצטט את תקן מס' 10 (ראיות הביקורת וניירות עבודה)

סעיף 19 – הנהלים לאיסוף ראיות העבודה עשויים להשפיע על נהלי הביקורת (ידניים, אלקטרוניים). בחברת השיווק הישיר קיימים קשיים – נדרשים כישורים של מנהל מערכות מידע.

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

נדרש ד' –

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

[כיום לא קיימת "מערכת" אבטחת מידע אלא מיושמת כבר בבסיס הנתונים, בשלב יישום וכו' ולכן כוונת השאלה היא שאין התייחסות לאבטחת המידע]

יש להתייחס לנתונים רגישים כגון: כרטיסי אשראי.

נספח א' בגל"ד 66 – בקרות כלליות:

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

ההשפעה על פעולתו של רו"ח – עליו לבדוק את הבקרות הקיימות ולהמליץ לחברה לאמץ בקרות פנימיות.

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

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

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

שיעור מס' 4

מטרות ביקורת בסביבת מערכות מידע ממוחשבות

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

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

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

3. שיפור תהליכי הביקורת – כאשר אנו נמצאים בסביבת מערכות מידע ממוחשבות ניתן להפעיל מנגנונים ממוחשבים לצורך עבודת הביקורת עצמה (s‘CAAT)

שלבי הביקורת

1. סקר ממ"מ

א. סקירה כללית של מערכות המידע – נספח א' בגל"ד 66 מנחה אותנו לאסוף מידע על מנת שנוכל להכיר את מערכות המידע של המבוקר...

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

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

ב. קביעת תוכנית ביקורת – בהתבסס על ניתוח סיכונים שהועלו ב"סקר הסיכונים" (נק' התורפה, כמה כדאי להשקיע, סדרי עדיפויות, לו"ז).

תוכנית הביקורת כוללת: לו"ז, סדרי עדיפויות, יעדים

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

סיכון שיורי – סיכון קיים שאין כנגדו שום בקרה.

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

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

א. הבקרה פועלת (אחרת עולה סיכון שיורי נוסף).

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

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

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

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

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

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

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

בדיקת איכות מידע ונתונים:

א. השוואה -

· למסמכי מקור (מתעוררת בעיה כאשר אין מסמכי מקור).

· נתונים פיסיים.

· גורמי חוץ.

· השוואה בין מאגרי מידע שונים באותו ארגון.

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

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

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

ניתוח סיכונים

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

יח' ארגונית/מחלקה [אמור לייצג את מבנה הארגון]	תהליך/פעילות [אמור לייצג את התהליכים והפעילויות]	תמיכה מיכונית [מערכת המידע הממוחשבת התומכת באותו תהליך]	איום [מושפע מנהלים, חומרה, משתמשים]	לא מושפע ממערכת מידע ממוחשבת אלא מושפע ישירות מהתהליך או הפעילות]	חומרה [איום X סיכון. את החומרה מדרגים בד"כ בין 1 ל-10]
מחסן	פתיחת מק"ט, עדכון מק"ט, החזרת פריט, ניפוק פריט, ספירת מלאי, כניסת מלאי וכו'	מערכת המלאי	8	5 3 1 10 2	5 8
כספים	...	המערכת הפיננסית

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

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

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

בעיות במודל

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

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

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

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

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

טכניקות בדיקות	בקרות	נתונים
ידניות	שאלון ביקורת מטריצת בקרה
ממוחשבות (s‘CAAT)	Test Data F.T.I	דוחות/שאילתות כלי שליפה וניתוח סטטיסטי תוכנות לביקורת ACL, IDEA סימולציה במקביל

מבקרות ניתן להסיק על נתונים ומנתונים ניתן להסיק על בקרות – קיים קשר ישיר.

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

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

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

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

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

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

שאלון מנחה את המשתמש לתשובה מסוימת. חשוב לשאול שאלות שלא ישפיעו על המשתמש.

מטריצת בקרה

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

הטורים מייצגים את האיומים.

[מפגש של טור ושורה תייצג האם קיימת בקרה על איום מסוים בגורם מסוים]

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

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

Test Data - הכנת סדרה של איומים מכסים פעילות עסקית מסוימת.

דוגמא: בדיקת מערכת מלאי.

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

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

חשוב שתוצאות הרצה של Test Dataיהיו על מערכת שהיא זהה למערכת המותקנת בסביבת הייצור.

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

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

בקרת הפרדת סביבות

סביבת הייצור – סביבת האמת. המערכת עובדת עם הנתונים האמיתיים.

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

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

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

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

על מנת שהבדיקות (בסביבת הבדיקות) יהיו קרובות לסביבת הייצור, כלומר כמה שיותר מהימנות יש לבצע העתקה מסביבת הייצור – לבצע סימולציה עם נתונים דומים לנתונים האמיתיים.

[לא פוגעים בשום אופן בסביבת הייצור]

הפקת דוחות ושאילתות

הדגש הוא בבדיקת התוצאות ולא הסיבות.

ניתן להגדיר 3 קבוצות של דוחות:

1. דוחות תפעוליים – סט הדוחות הסטנדרטי של המערכת.

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

סביר להניח שהנתונים בדוחות הסטנדרטיים תקינים.

החיסרון בכך – לא מתאים לביקורת ספציפית.

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

היתרון – מובנה במערכת ומיועד לצורכי ביקורת.

החיסרון – לעיתים נדרשים לעזרה של גורמים נוספים.

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

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

שימוש בכלי שליפה וניתוח סטטיסטי

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

מדובר בכלים סטנדרטיים הנמצאים בשוק, כגון: אקסל, אקסס, SAS וכו'.

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

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

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

חיסרון – בעיה בביצוע גזירת הנתונים. גזירת נתונים נכונה לתאריך ולאוכלוסייה מסוימת.

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

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

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

תוכנות לביקורת (ACL, IDEA)

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

התוכנות מאפשרות פעולות מיון, איתור כפילויות, אפשרויות דגימה שונות.

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

יתרונות – אי תלות, קלות שימוש.

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

סימולציה במקביל

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

יש לקחת את נתוני הקלט המקוריים ולהכניס אותם לתוך מערכת מידע ממוחשבת של המבקר (אקסל, ויזואל בייסיק, C++ וכו').

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

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

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

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

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

היתרון – עובדים על קבצי הקלט המקוריים.

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

F.T.I (Integrated Test Facility)

מערכת בדיקה משולבת – שימוש ביישות דמה לצורכי מיסוי בלבד.

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

הנתונים מוזנים בסביבת הייצור האמיתית.

החיסרון – מכניס נתונים מיותרים לסביבת הייצור.

היתרון – בדיקת המערכת בסביבה חיה והבדיקה נערכת לאורך זמן.

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

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

לקרוא - נספח ה' לגל"ד 66 דן בטכניקות ביקורת של מערכות ממוחשבות.

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

שיעור מס' 5

אמצעי בקרה

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

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

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

בקרות ארגוניות סביבתיות –

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

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

בקרות גישה – לוגיות ופיסיות.

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

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

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

שלבי עיבוד המידע:

1. קלט

2. עיבוד

3. פלט

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

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

קיימת גישה אלטרנטיבית לחלוקת הבקרות –

מעקב ופיקוח

מבוזרות

ספציפיות

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

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

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

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

מדובר בבקרה המתקרבת למה שמתרחש במציאות (כבר לא מדובר בחלוקת הבקרות בצורה מופשטת וכללית).

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

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

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

נהוג לחלק את עולם הבקרות לשלושה סוגים בהתאם לרמת ה"חוזקה" שלהן:

1. בקרה "מגלה"/"מתריעה" – הבקרה מגלה נתון שגוי אך לא מונעת את המשך התהליך או את המשך הקליטה והעיבוד את העסקה.

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

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

נשאלת השאלה - האם מבחינה לוגית ניתן לתקן נתון שגוי.

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

בקרות קלט, פלט ועיבוד

ההגיון אומר כי סביר למצוא את מרבית הבקרות בשלב הקלט. בכל מקרה לא ניתן לקבוע את 100% הבקרות בשלב הקלט (מאילוצי זמן ומשאבים וכן תמיד קיימת סבירות שהנתונים השגויים יעברו הלאה).

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

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

בקרות קלט

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

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

קשה לזהות טעויות בשיטה זו – לעיתים תוצאת החישוב שווה באופן מקרי לספרת הביקורת או שספרת הביקורת השתבשה.

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

בקרה זו רלוונטית בעיקר למערכות batch – רישום הנתון נוצר במנותק מההזנה ולכן ניתן לבדוק נתונים בדיעבד.

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

דוגמא -

להלן קובץ חשבוניות:

מס' סכום מטבע סכום בש"ח

10 1,200 $ 5,000

144 50 DM 140

2 145.3 ₪ 145.3

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

156 1,395.3 לא רלוונטי 5,295.3

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

סיכום מס' החשבוניות או של סכומי החשבוניות הוא חסר משמעות (סיכום שורת הסכום בש"ח לעומת זאת הוא סיכום ביקורת).

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

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

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

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

בקרת סבירות - בדיקה הנעשית ברמה של רשומה/קובץ. קולטים מס' רשומות שעברו את כל בדיקות התקינות. למשל: במכשיר כספומט נקלטו 100 משיכות של 20 ₪ - סה"כ הסכום שנמשך הוא 2,000 ₪ אך לא סביר כי אדם שרוצה למשוך 2,000 ₪ יעשה זאת ב- 20 משיכות.

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

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

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

רציפות עוזרת לאתר איזה רשומה הושמטה למשל.

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

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

לדוגמא: לשדה המייצג תאריך – תחום הערכים לגבי יום הוא בין 0 – 31, תחום הערכים של חודש

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

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

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

בקרת שגויים

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

לעיתים חלק מנתוני הקלט זוהו כתקינים וחלקם זוהו כשגויים (כתוצאה של אחת הבקרות הנ"ל).

קיימות שלוש אפשרויות לטיפול בנתונים שגויים:

1. לדחות את הנתון השגוי ולמנוע את המשך עיבודו.

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

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

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

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

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

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

דוגמא –

קליטת פקודת יומן במערכת הפיננסית.

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

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

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

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

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

בקרות עיבוד

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

בקרות עיבוד הכוונה היא ל:

1. תזמון של המהלכים והעיבודים שמבוצעים במערכת – סדר נכון של פעולות (במקביל, בטור, שילובים).

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

3. שלמות ודיוק של תהליכי העיבוד – ביצוע עיבוד על כל הרשומות שהוכנסו בקלט.

4. אבטחת מידע.

שלמות ודיוק

ישנה טכניקה שאופיינית למערכות batch שנקראת run 2 run – אם יש סדרה של מהלכים, יש לבודד כל מהלך על מנת לבדוק כל מהלך בנפרד.

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

בקרת הקלט – יש לבדוק שמתקיימת המשוואה input = output (לכן בקרת העיבוד נקראת גם בקרת "איזון").

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

לעיתים מתקיימות כמה פעולות במקביל ולכן יש לבנות מערכת של איזונים ותזמונים (יומי, תקופתי וכו'). מומלץ שתהיה אפשרות לעשות זאת באמצעות המערכת.

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

ש.ב.א (יומי)

דחויים

תקינים

שגויים

	קובץ טקסט )log file(
שגויים

משוואת האיזון היומית:

דחויים + שגויים + תקינים = שגויים IN + שוברים + ויזה + ש.ב.א

בקרות פלט

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

קיימים כמה סוגים של דוחות פלט:

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

2. הצגת מידע הכולל חישובים מסוימים על הנתונים שנלקחו ממאגרי המידע (on the fly) – לעיתים נדרשים ניתוחים אנלטיים שלא נרצה לערוך במסגרת מאגרי המידע.

3. דוחות מיוחדים – דוחות בקרה ופיקוח – אותם הדוחות השולפים מידע בצורה סלקטיבית, שולפים חריגים ושגויים. אותם נתונים יושבים במאגרי המידע או בקבצים נפרדים (קובץ שגויים).

על לוודא שכל שלושת קבוצות הדוחות יופקו באופן תקין ניתן לנצל חלק מהבקרות הקשורות לקלט –

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

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

[קשה מאוד לבדוק תקינות של פלט]

נתיב ביקורת

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

דוגמא: מכירה.

הזמנת לקוח, מכירה - חשבונית, שליחה - תעודת משלוח, גבייה – קבלה.

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

נתיב הביקורת של מערכת מידע –

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

למשל אסמכתא להפקת חשבונית היא הזמנה וכך הלאה.

ברישום כרטיס הלקוח יש להזין את מס' החשבונית. כמו כן אותו לקוח מסומן שהוא שייך ללקוחות בארץ וכנ"ל בקשר לרישום ברכוש השוטף.

רשימת האסמכתאות מאפשרות את אותו פירוק.

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

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

לדוגמא: סטטוס 0 – הזמנה פתוחה, סטטוס 1 – הופקה חשבונית, סטטוס 2 – נשלחה, סטטוס 3 – גביית התשלום, סטטוס 4 – הזמנה סגורה.

אם משתמש מסוים מנסה להעביר יישום מסוימת מסטטוס 0 לסטטוס 3 – המערכת אמורה להתריע על מעבר לא חוקי בין הסטטוסים.

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

יש לציין שנדרשים שני ההיבטים (החשבונאי והתפעולי).

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

נתיב ביקורת משמש לצורך

1. איתור שגיאות ובאיזה שלב של התהליך קרתה השגיאה.

2. שיקום ושחזור.

3. אפשרות לפקח על היישום.

4. הרתעה בפני מעילות.

[לקרוא את השאלה והפתרון ממבחן מועצה חורף 96]

שיעור מס' 6

מערכת ERP – פריוריטי

בתהליכים שונים קיימים ממשקים בין המערכות השונות (ממשק בין מערכת הכספים והמכירות, ממשק בין מערכת הכספים והרכש, ממשק בין מערכת המכירות למערכת המלאי וכו').

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

בשולחן העבודה קיים האייכון של priority.

נפתח מסך לוגי – לסגור אותו.

מקבלים מסך של המערכת.

[סימן של גלגלי שיניים – מריץ תוכנית, סימן של טבלה כחולה – הזנת נתונים וסימן של ספר פתוח – דוחות]

הקמת חברה חדשה –

בתפריט הראשי – מנהל המערכת – תחזוקת מערכת – טיפול בחברות – הוספת חברה –

נפתח מסך המבקש פרמטרים לקליטה:

1. חברה – להשאיר ריק

2. שם חברה מלא – לרשום שם מלא + תעודת זהות.

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

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

הגדרת תקופה -

כספים – הנהלת חשבונות – תקופות כספיות – שנות כספים –

· יש להגדיר שנת כספים כשנת 2001

· תאריך התחלה – 1/1/01

· תאריך סיום – 31/12/01

[על ידי לחיצה על 1F, כאשר עומדים על שדה מסוים, נפתח הסבר על אותו השדה]

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

כספים – הנהלת חשבונות – תקופות כספיות – פתיחת תקופה –

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

אנו צריכים לעשות את אותה פעולה 12 פעמים עבור 12 החודשים של השנה (בפועל הפעולה מתרחשת פעם בחודש).

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

עתה יש להגדיר את מערכת החשבונות – מכירות, מלאי וכו'.

אתחול חשבונות –

כספים – תחזוקת כספים – הגדרות כספים – איתחול חשבונות-ישראל –

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

ב"תיאור החשבון" ניתן לבחור חשבון מסוים מתוך רשימה (כל החשבונות הראשיים).

פתיחת לקוחות –

קיימות רמות שונות של לקוחות. ניתן לפתוח מס' חשבונות תחת "החשבון הראשי" – 001.

כספים – הנהלת חשבונות – כרטיסי חשבונות – חשבונות לקוחות –

חשבון – 110

תאור החשבון – לקוח 1

כך הלאה על מנת לפתוח 4 לקוחות.

* צריך לבדוק שהמטבע אכן בש"ח.

פתיחת ספקים –

כספים – הנהלת חשבונות – כרטיסי חשבונות – חשבונות ספקים –

באותו אופן יש להגדיר חשבון ספק – מומלץ לפתוח חשבון מס' 200.

אתחול חשבונות מלאי –

יש לפתוח תעודות הזמנה, תעודות משלוח וכו'

ניהול מלאי – תחזוקת מלאי – הכנת תבניות מספר לתעודות –

במסך קליטת הנתונים יש לבחור בשנת הכספים 2001.

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

הוספת פריטים –

ניהול מלאי – מוצרים – כרטיס פריט –

נפתח מסך של פתיחת פריטים:

· מק"ט – 300.

· תיאור מוצר – שולחן משרדי.

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

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

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

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

בתרגיל עובדים עם ספק אחד ולקוח אחד במסגרת עסקה 1 ובמסגרת עסקה 2 עובדים עם ספק 2 ולקוח 2.

עסקאות רכישה

קליטת הצעת מחיר מספק -

רכש – הצעות מחיר – הצעת מחיר מספק –

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

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

· תאריך – מומלץ להכניס תאריכים הגיוניים.

· בתוקף עד – כנ"ל

· הצעת מחיר – יש לרשום לעצמנו את מס' ההצעה שניתנה ע"י המערכת.

לאחר מכן יש ללחוץ על החוצץ של "הצעת מחיר מספק – פירוט" – במסך זה יש להקליט מהם ההצעות שניתנו –

· מק"ט – יש לבחור מתוך תיבת הבחירה את הפריט הרלוונטי מתוך הפריטים שהכנסנו קודם.

· תאור המוצר – נפתח אוטומטית.

· כמות מינימום – 200 (שולחנות).

· מחיר ליחידה – 100 ₪.

יש לזכור לרשום שהצעה כוללת נספחים (Y) וכן להפוך את שדה ה"סטטוס" מטיוטא למאושרת.

לבסוף יש לצאת מהמסך והנתונים נשמרים.

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

הפקת הזמנה לספק –

רכש – הזמנות רכש – הזמנות רכש –

· ספק – ספק 1.

· תאריך – מופיע אוטומטית.

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

· הזמנה – המערכת נותנת מס'. לעיתים מס' ההזמנה זהה להצעת הרכש אך זה לא משנה – מומלץ גם כאן לרשום את המספר לעצמנו.

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

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

בכדי לבדוק את ההזמנה נכנסים לרכש – הזמנות רכש – דוחות הזמנות רכש -

קליטת חשבונית מספק –

כספים – רכש (כספים) – חשבוניות רכש – חשבוניות ספק – חשבוניות ספק –

· תאריך – מומלץ לעבוד עם התאריך של היום.

· חשבונית ספק – אם עובדים עם ספק 1 יש להתחיל עם 100A ובעסקאות הבאות להקליד 101A, 102A וכו'.

· מס' ספק – לבחור מתיבת הבחירה.

· הזמנה – בתיבת הבחירה מופיעות כל ההזמנות מספק 1 שאושרו.

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

את הכמות (שהתקבלה) יש להזין בעצמנו.

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

לחיצה על הלשונית "סגירת החשבונית" - מהלך סגירת חשבונית – אישור שבעקבותיו מופקת פקודת יומן בספרים (ניתן לראות שנפתח מס' פקודת יומן).

ליד מס' פקודת היומן מופיע אייכון של סייר – לחיצה עליו פותחת חלון המפרט את נתוני פקודת היומן.

עסקאות מכירה

הפקת הצעת מחיר ללקוח -

שיווק ומכירות – הצעות מחיר – הצעת מחיר ללקוח –

· לקוח – לקוח 1 (110).

· תאריך – נפתח אוטומטית.

· הצעת מחיר – 1000001A.

לשונית הצעת מחיר ללקוח – פירוט – ניתן לפתוח כמה רשומות.

· מק"ט – 300 (שולחן משרדי).

· כמות מינימום – 100 – נפתח אוטומטית.

· מחיר ליחידה – יש לשנות את המחיר ל- 120.

· עלות הקנייה – מופיע אוטומטית.

יש לזכור לשנות בסוף התהליך את הסטטוס ל- "נשלחה".

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

קליטת הזמנה מלקוח –

שיווק ומכירות – הזמנות – הזמנות לקוח –

נפתח מסך של קליטת הזמנה –

· לקוח – בחירה מתוך התיבה - לקוח 1 (110)

· תאריך – נפתח אוטומטית.

· הזמנה – כנ"ל.

· הצעת מחיר – יש לבחור במס' הצעת המחיר שהזנו קודם.

כרטסת פירוט הזמנה (או ע"י לחיצה על ALL) – יש לוודא האם הפרטים מקובלים בהתאם להזמנה.

לבסוף יש לשנות את הסטטוס ל- "בוצעה".

[מומלץ לצאת משדה הסטטוס לפני שיוצאים מהחלון]

הפקת דוח – שיווק ומכירות – הזמנות – דוחות הזמנות – דוחות מפורטים – דוחות הזמנות – הזמנות לפי לקוח.

הפקת חשבונית ללקוח –

כספים – מכירות (כספים) – חשבוניות מכירות – חשבוניות מס – חשבוניות מס –

· לקוח – לקוח 1.

· תאריך – נפתח אוטומטית תאריך של היום.

· חשבונית – מספור אוטומטית ע"פ חוק.

· הזמנה – יש לבחור בהזמנה שביצענו מתוך תיבת הבחירה.

פירוט החשבונית – יש לבדוק את הנתונים, את מחיר היחידה וכו'. יש להקליד את הכמות!

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

כדי לסגור את החשבונית כולה יש לעלות לכותרת וללחוץ על החוצץ "סגירת החשבונית".

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

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

שמירה על דיסקט והגדרות הדפסה

כספים – הנהלת חשבונות – כרטיסי חשבונות – דוחות כספיים – כרטסת – כרטסת –

· לסמן כדף HTML.

· לסמן – כל הכרטסות.

בכל שאר החלונות שנפתחו יש לרשום OK.

בסופו של דבר נפתח חלון של ה-EXPLORER ובו מפורטים כל החשבונות.

חס – חשבונות ספק

חל – חשבונות לקוח

מע"מ עסקאות – מול הלקוח

מע"מ תשומות – מול הספק

בכדי להפיק את הדוח –

קובץ – שמור בשם – לבחור בשמירה על דיסקט – לשמור את הקובץ בשם של החברה (מס' תעודת הזהות של אותו אדם שרשם את החברה על שמו).

הקובץ הוא מסוג HTML ולכן אין בעיה להדפיס מכל מחשב.

שיעור מס' 7

ביקורת מ.מ.מ. ביישומים

מערכת פיננסית

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

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

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

מעגל רכש –

דרישה – הזמנה – כניסה – חשבונית – תשלום.

מעגל המכירות –

הזמנה – משלוח – חשבונית – גבייה.

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

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

היררכית המערכת הפיננסית:

1. הספר הראשי (GL) – תת המערכת המרכזת את כל הרישומים החשבונאים לצורך הפקת דוחות כספיים וכל אינפורמציה נוספת למנהלים כנדרש.

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

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

· ספקים ותשלומים (AP)

· לקוחות וגבייה (AR)

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

· רכוש קבוע (FA)

· תקציב

· תמחיר

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

זרימת הנתונים בארגון

מערכת פיננסית:

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

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

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

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

דוגמא:

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

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

אפשרות 2 – קליטת החשבונית במערכת הרכש, מעבר למודול ספקים ותשלומים (אחרי שעברה את כל הבדיקות במערכת הרכש) – הטיפול עובר לאנשי הכספים ומשם מעבר לספר הראשי.

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

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

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

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

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

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

תכונות של מערכת פיננסית

1. תמיכה בהליכים העסקיים שבארגון – הליכים עסקיים כללים (רכש מכירות וכו') והליכים שבתוך אגף הכספים.

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

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

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

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

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

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

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

דוגמא:

בחברה 1,000 ספקים. נשאלת השאלה האם ניתן לנהל בספר הראשי חשבון אחד לספקים או לנהל חשבון לכל ספק.

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

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

המערכת הפיננסית כפופה להוראות חוק –

הפקת דוחות כספיים – גילויי דעת של לשכת רו"ח

ניהול ספרים – הוראות ניהול ספרים של מס הכנסה.

כללים חשבונאיים – הוראות הרשות לני"ע.

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

במערכת הפיננסית קיימים קבצי תנועות וקבצי יתרות -

קבצי תנועות = קבצי אב

קבצי יתרות – פרטניות. קבצי יתרות מאפשרים צפייה ביתרות באופן זמין יחסית.

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

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

חוקה

טבלאות עזר

אמצעי בקרה ונתיבי ביקורת

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

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

2. נתיבי ביקורת – לגבי כל ספר עזר.

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

קיים מונח שנקרא "סגירת תקופה" – עוצרים את הניפוקים שבוצעו עד סוף החודש וכל ניפוק שהתבצע מאוחר יותר נכנס לחודש העוקב. נניח שהמכירה בוצעה ב- 31/1 והסחורה נשלחה ב- 5/2. הגריעה מהמלאי הייתה אכן ב- 5/2 אך המכירה נרשמה בחודש הקודם.

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

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

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

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

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

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

סכומים – לעיתים קיימים סכומים הנקובים במטבעות שונים.

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

תאריך הרישום = תאריך רישום הפקודה בספרים – אין בעיה להציב בקרות קלט על שדה תאריך הרישום.

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

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

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

תאריך תקופה חשבונאית – לעיתים נדרשים לייחס חשבונות לתקופה חשבונאית אחרת (אירועים מסוג א', אירועים מסוג ב' וכו').

דוגמא:

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

תאריך הרישום = 7/2

תאריך הערך = 2/2 – תלוי מה נקבע מול הספק (בד"כ נקבע ששער החליפין הוא לפי תאריך החשבונית).

תאריך הפירעון – בהנחה שמדובר בשוטף + 60 – יש לקחת את תאריך החשבונית ועוד 60 ימים ולכן - 30/4.

תאריך תקופה חשבונאית – שנת 2000 – בהתאם לחודש סיום העבודה.

דוגמא:

סכומים בהקשר לרב מטבעיות

חשבונית התקבלה ב- 1/1/01 מספק בגרמניה על סך 100 DM. הספק מנוהל בחשבון הנקוב ב- DM.

תאריך	פרטים	סכום	מטבע	סכום ח-ן ב- DM	שע"ח	סכום בש"ח	שע"ח $	סכום ב- $
1/1/01	ח-ן	100	DM	100	2:1	200	4:1	50
31/12/01				100	3:1	300	5:1	60

מומלץ לעשות שערוך לפי כל תנועה.

יש לבצע ראשית שערוך לש"ח ולאחר מכן שערוך ל- $ ("אנטי שערוך").

ש"ח תרגום $ $ - התשובה האמיתית!

ספק 300 60 60

שערוך 100 20 10

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

המערכת נדרשת לשקף נכונה את מה שקרה ואכן השערוך אמור להיות 10.

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

הוראות אלו קבעו איך לנהל את ספרי החשבונות השונים.

ספר ראשי – חובה לכל הארגונים

ספר מלאי – למי שמנהל מלאי.

ספר קופה – למי שמנהל מפרט וכו'.

תיעוד פנים – כל מסמך שמופק מטעם הנישום (הפקת קבלה בקבלת תקבול, הפקת תעודת משלוח וכו').

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

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

ספר כרוך – ספר כרוך שדפיו ממוספרים בסדר עולה וכאשר נתלש דף נותר העתק…

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

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

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

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

נספח ה' – הוסף במיוחד למערכות מידע ממוחשבות.

התוכנה לניהול מערכת חשבונות ממוחשבת תבצע בין היתר –

1. הפקה זמינה של פלט חזותי לפי סדר רישומן...

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

3. ציון בצורה בולטת של המילה "טיוטא" על גבי פלט חזותי המונפק באופן זמני – על מנת להבדיל בין קובץ קבוע לבין קובץ בלתי קבוע.

4. הפקת פלט מודפס של תיעוד פנים מקובץ קבוע בלבד – כל מה שנדרש לגבי ספרי חשבונות נכון גם לגבי תיעוד פנים.

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

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

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

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

לקרוא את ההוראות!

מערכת מלאי

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

מערכת המלאי נקראת גם "ספר עזר המלאי" או "מלאי פיננסי".

ניפוק תוצ"ג ניפוק חו"ג

מלאי

כניסת חו"ג מלאי תמידי

ניפוק חו"ג כניסת תוצ"ג

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

השיוך נדרש למטרות שונות, למשל:

מלאי שהוא רכוש קבוע (חלקי חילוף וכו'). קיימת מערכת לניהול מלאי מיוחד באותו אופן שבו מנוהל מלאי רגיל.

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

ניתן לנהל ערך מלאי ברמת מחסן ולא רק ברמת החברה (מסובך יותר).

עיתוד מלאי – מתייחס לנושא שמירה על רמות מלאי - מלאי מינ', מלאי מקס' וכו'. לא נדבר במסגרת הקורס.

נושאים שנדון בהם בשיעור הבא:

קטלוג פריטים

ערך מלאי

שיעור מס' 8

מערכת המלאי – המשך

תנועה: כמות * מחיר = ערך

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

· גריעה (פסילה השמדה).

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

· שינוי מחיר – משפיע על מרכיב המחיר במשוואה.

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

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

קובץ יתרות – באמצעותו ניתן לצפות באופן מהיר על יתרת הפריט לתקופה מסוימת.

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

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

מס' היצרן מזהה את הסימון של אותו פריט אצל היצרן.

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

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

ניהול ערך המלאי (מלאי פיננסי)

מלאי ניתן לנהל בכמה שיטות – LIFO, FIFO, ממוצע נע, ספציפי, תקן.

LIFO אינו נהוג בד"כ.

השיטות הנהוגות הןFIFO וממוצע נע ערך – בשיטות אלו ערך המלאי גבוה יותר וכן מתאים יותר לניהול פריטי מלאי (LIFO מתאים לניהול פריטי מלאי נוזליים).

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

ב- FIFO נשתמש כאשר ניתן למדוד את אורך חיי המוצר (תאריך תפוגה) – נותן תמונה טובה יותר.

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

מלאי תקן – נהוג לניהול מלאי תוצ"ג (כאשר יש עצי מוצר). מלאי תקן משמעותו שמחיר כל פריט במלאי נקבע ע"פ מחירון (תקן).

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

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

מלאי תמידי – מלאי תקופתי.

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

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

הרישום בהנה"ח –

דוגמא:

כניסת חו"ג – מס' פריט 1010, כמות – 10, מחיר – 8

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

[כאשר תגיע חשבונית נחייב ספקים במעבר ונזכה ספק]

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

נניח שכאשר הגיעה החשבונית הסכום היה 90 (בעקבות שינוי בשע"ח למשל) –

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

אם כל הפריטים מצויים במלאי – נזכה את חשבון ספקים במלאי ונחייב את חשבון המלאי ב- 10.

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

על מנת לטפל במצבים כאלו קיימים במערכת המלאי מהלכי עדכון רטרואקטיביים (roll back) -

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

דוגמא –

פרטים	כמות	מחיר	ערך	ממוצע נע
כניסה 1	10	10 10.5	100 105	10 10.5
כניסה 2	10	12	120	11 = 20 / 220
סיכום ביניים	20		220 225	11 11.25
ניפוק	(5)	11 11.25	(55) (56.25)	11 11.25
סיכום ביניים	15	3.75	165 168.75	11 11.25
חשבונית בגין כניסה 1	10	10.5	105

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

הייחוס יהיה ביחס של 3:1 (נופקו 5 פריטים ונותרו 15 פריטים) כלומר –

1.25 לעלות המכר ו- 3.75 למלאי.

ח' מלאי 3.75

ז' ספקים במעבר

ח' עלות המכר 1.25

ז' ספקים במעבר

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

כאשר יש החזרות – האם לעשות roll back או לא, לפי איזה מחיר לבצע את המהלכים?

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

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

אילו הפריטים שעל המדף אינם תואמים את מס' הפריטים שבמערכת (יש יותר פריטים על המדף מאשר רשומים במערכת) – ניתן לתקן את מס' הפריטים שבמערכת ולהנפיק את המלאי אולם זה לא תמיד מתאפשר.

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

פרטים	כמות	מחיר	ערך	ממוצע נע
כניסה 1	10	10	100	10
כניסה 2	10	12	120	11 = 20 / 220
סיכום ביניים	20		220	11
ניפוק 1	(15)	11	(165)	11
סיכום ביניים	5		55	11
ניפוק 2	(10)	11	(110)
סיכום ביניים	(5)		(55)	11
כניסה 3	10	13	130	??
סיכום ביניים	5		75	15

?? - המחיר הממוצע חייב להיות בין 10 – 13 ולכן לא מסתדר לרשום מחיר בסך 15.

ניתן להחליט שהכניסה הראשונה שהעלתה את המלאי מכמות שלילית לחיובית תקבע את המחיר – כלומר נתחיל מלמטה למעלה לפי מחיר 13.

יש לתת פקודה בגין תיקון מלאי שלילי בסך 10 יחידות (בד"כ כנגד רווה"פ).

חשבון ספקים במעבר -

כניסות ללא חשבוניות

(חשבוניות ללא כניסות)

הפרשי מחיר

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

שיעור מעבדה – יום שלישי, 25/12/01, בשעה 16:45 – 19:00.

שאלה ממבחן – חברת "פטישי הנגב"

מע' ייצור מע' מלאי מע' מכירות

מע' שכר

חו"ג עבודה מע' הנה"ח

נדרש א' –

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

בקרות בתהליכי העבודה במערכת המכירות:

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

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

3. ביצירת חשבונית לא ניתן יהיה להזין מוצרים שלא יהיו קיימים בקובץ טבלאות מלאי (קובץ הפריטים שבמלאי).

4. ההנחות ללקוחות ייקבעו בקובץ נפרד ולא ניתן יהיה לשנות בחשבונית את סוג ההנחות (ההנחות ימוספרו ויינתנו רק בסוגי עסקאות שייקבעו).

5. רציפות חשבוניות.

6. בקרות גישה והרשאות.

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

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

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

ד. בכל שלב יהיה ניתן לחזור לנתונים היסטוריים בכל הטבלאות.

תכנית ביקורת למערכת המכירות

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

2. בדיקת רציפות של מס' סידורי של חשבוניות המס.

3. רציפות של תעודות משלוח.

4. בדיקת כפילות של חשבוניות מס או של תעודות משלוח .

5. התפלגות מכירות ע"פ תקופות, פילוח גיאוגרפי וכו'.

6. בדיקת סך התקבולים לסך העברות להנה"ח.

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

נדרש ב' –

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

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

שלב קליטת עובדים חדשים –

1. לא לאפשר רישום של שני עובדים עם אותה תעודת זהות – מפתח ראשי בקובץ.

2. בדיקת ספרת הביקורת.

3. לא לאפשר הזנה של מס' ת.ז ללא משמעות.

4. שדות תעודת זהות כגון: שם העובד, כתובת ופרטי בנק – שדות חובה (לפי הוראות ניהול ספרים).

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

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

7. בדיקת חריגים כגון: כתובות או חשבונות בנק כפולים.

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

שלב הפקת תלושי שכר –

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

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

3. התאמת פרטי השכר לקבצי כוח אדם בנושאים: דרגות, ותק, אחוזי משרה, נקודות זכות וכו'.

נדרש ג' –

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

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

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

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

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

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

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

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

7. בקרות גישה.

8. דוחות שגויים וקבצי תיעוד.

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

1. בדיקת סיכומים והכפלות (יח' * כמות = ערך).

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

3. עריכת גיול של המלאי על פי תאריכי כניסה.

4. זהה ואתר את פריטי המלאי שכמותם עולה על רמות המלאי המקסימליות (במידה והמערכת תומכת בהגדרת רמות מקס').

5. זהה ואתר מלאי איטי ומלאי פגום (בד"כ עורכים בדיקת תנועות שנעשו לכל רבעון על מנת לאתר מק"ט שקיימים ביתרות ולא נעשו בהם תנועות – אין תחלופה).

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

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

8. בדיקות חתך.

9. השוואת הכמויות במערכת לספירות המלאי (בד"כ במערכות המנהלות מלאי תקופתי).

10. זיהוי פריטים ותנועות מלאי כפולים.

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

12. זהה ואתר מלאי שנרכש מחברות בעלות עניין.

נדרש ד' –

דוחות לעיון במערכת על מנת לבדוק חריגות:

במערכת שכר -

1. תנועות במצבת כוח אדם.

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

3. עובדים שחלה במשכורתם עלייה דרסטית במהלך השנה.

במערכת המלאי –

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

2. פקודות עבודה שלא הופקו בגינן תעודות משלוח.

3. פקודות עבודה עם כמויות חריגות.

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

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

מערכת מכירות –

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

2. התפלגות מכירות על פי חתך מסוים (לקוחות, חודשים וכו').

3. קובץ הנחות, קובץ מחירים, מק"טים, קובץ חשבוניות.

שאלה ממבחן 5/1/98

נדרש 1 -

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

1. מאגר ספקים – מס' ספק (מפתח), כתובת הספק, פרטים, ניכוי במקור, צורת תשלום, תנאי תשלום.

2. מאגר פריטים – מס' פריט (מפתח), תיאור, יחידות מידה, ספק מועדף, מחיר מחירון.

3. מאגר קניינים – ת.ז (מפתח), מס' עובד, שם הקניין.

4. מאגר דרישות רכש – מס' דרישה (מפתח), תאריך, הגורם היוזם את הדרישה, הגורם המאשר, תאריך נדרש, פריט, כמות, סטטוס.

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

6. מאגר חשבוניות רכש – מס' חשבונית (מפתח), סה"כ מבחינת ערך, מע"מ תשומות.

נדרש 2 –

בקרות הקלט שנצפה למצוא במסך הזנת ההזמנה:

· מס' הזמנה – מספור אוטומטי – מונע כפילויות ופערים.

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

תיעוד שם העובד או הקניין.

· תאריך – פורמט תאריכי, ברירת מחדל תהיה התאריך של היום.

· מס' ספק – יירשם רק ספק מתוך רשימת הספקים (שדה מפתח ברשימת הספקים).

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

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

· מועד אספקה – בדיקה האם תאריך האספקה עומד בתאריך הדרישה.

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

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

· מס' פריט בהזמנה – בדיקת קיום בטבלת פריטים.

הפרטים בגין אותו מק"ט יוצגו אוטומטית.

יש לציין שלא כל המק"ט יאושרו להזמנה.

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

· מחיר ליחידה - המערכת לא תאפשר הזנת מחיר בדרישת הרכש ובהזמנה תופיע ברירת המחדל בהתאם לטבלת המק"טים.

· דרישות רכש – יידרש להזין מס' דרישה מסוימת שהופקה בעבר. נתוני הדרישה יועלו אוטומטית.

· שדות חובה – כמות הזמנה, מק"ט, תאריך הזמנה, מס' ספק, מס' קניין, סעיף תקציבי, מועד אספקה.

שיעור מס' 9

עקרונות אבטחת מידע

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

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

בקרות גישה, אמצעי זיהוי ואימות, סקר עיסוקים

Availability – זמינות המידע. המידע אמור להיות זמין לצורך קבלת ההחלטות.

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

Integrity – מהימנות המידע. הכוונה לשלמות ודיוק המידע.

בקרות ממשק, עיבוד שלם ומלא של מידע, בקרות בקליטת מידע.

תפקידי המבקר

נספח א' לגילוי דעת 66 מדבר על בקרות כלליות (במסגרת סקר על הבקרה הפנימית) –

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

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

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

· ווידוי קיום גורם מקצועי אחראי לנושא.

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

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

מדיניות אבטחת מידע

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

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

מס' כללים:

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

· הגדרת המדיה שעל גביה שמור המידע.

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

בעלי המידע – אחראים לאבטחת המידע שברשותם.

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

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

· סיווג המידע – מידע רגיש, סודי וכו'. יש לקבוע קריטריונים לסיווג המידע.

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

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

· הערכות לשעת חירום.

· גיבוי הנתונים.

· אבטחה פיסית.

בקרות לוגיות ובקרות פיסיות

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

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

מערכת הפעלה – מקשרת בין החומרות השונות המותקנות במחשב.

בסיס הנתונים מכיל את טבלאות הנתונים.

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

יישומים

תהליכים

בסיס הנתונים

טבלאות, נתונים, שדות

מערכת ההפעלה

קבצים, ספריות, התקני חומרה

מדפסת

מצלמה

סורק

דיסק

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

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

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

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

ניהול ההרשאות הלוגיות מתבצע באמצעות הרשאות שמעניקים למשתמש מסוים או לקבוצת משתמשים (groups).

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

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

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

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

אבטחה לוגית – שיטות זיהוי

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

א. נתון מוכר למשתמש – שם משתמש בצירוף של סיסמה.

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

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

ד. סיסמאות.

בקרות הקשורות לסיסמאות –

o תדירות שינוי סיסמה לפי מכון התקנים צריכה להיות בין 60 ל-90 יום.

o אורך תווים מינימלי צריך להיות לפי מכון התקנים בין 4 ל-8 תווים.

o הגבלת מס' ניסיונות הזנה לפני ניתוק לפי מכון התקנים הוא בין 3 ל-5.

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

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

o שימוש בתווים מסוימים לבניית הסיסמא (מומלץ לכפות שימוש בכמה שיותר סוגי תווים – מספרים, אותיות, סימנים וכו').

אבטחה לוגית – הצפנה

הגדרה: תהליך הפיכת מידע גלוי לחסוי.

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

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

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

האלגוריתם עצמו אינו חסוי אלא המפתח הוא הגורם החסוי (סיסמה למשל). על מנת לפענח את המפתח החסוי קיים גם מפתח מפענח.

שיטות הצפנה:

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

האלגוריתם המפורסם ביותר בשיטת הצפנה זו הוא DES (standard data encryption).

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

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

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

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

האלגוריתם המפורסם ביותר הוא RSA .

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

המפתח הפרטי הוא סודי למשתמש. בשיטה הקודמת המפתח משותף למס' משתמשים.

המפתח הציבורי זמין לכל.

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

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

מטרה ראשונית של טכנולוגיות ההצפנה – להצפין מסרים. מטרה נוספת היא אימות וזיהוי.

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

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

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

בחוק קיים פרק שמטפל במצב שבו המפתח נחשף לגורמים בלתי רצויים.

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

(digital signature standard)

חוק החתימה הדיגיטלית בישראל נכנס לתוקף רק מאוחר יותר (השנה).

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

אמצעי אבטחה פיסית –

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

· נזקי טבע (רעידת אדמה, ברק, סופה, הצפה) – גלאי הצפה, רצפה צפה וכו'.

· נזקים סביבתיים – חומרים רעילים.

· פגיעה במערכות המחשב – נפילת מתח, ניתוק תקשורת.

· פשיעה – גניבה או חבלה.

יש לציין שהבקרות הלוגיות הן חסרות משמעות ברגע שלא מתקיימות הבקרות הפיסיות.

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

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

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

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

סיכוני טמפרטורה – חדר המחשב צריך להישמר בטמפרטורה מסוימת.

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

תוכנית למצבי אסון DRP

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

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

א. הגדרת אירועים – מהם אירועי חירום ומי מוסמך להכריז על מצב חירום.

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

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

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

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

אסטרטגיות ארגוניות לתכנית התאוששות

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

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

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

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

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

שיטות לגיבוי המידע

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

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

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

הרכיבים שיש לגבות:

· קבצי הנתונים (לקוחות, ספקים וכו').

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

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

· חומרה – שרתים, מחשבים, נתבים וכו'.

· מסמכים – תעודות אחריות, מדריך הפעלה, נהלים, שרטוטי רשת וכו'.

· רשימות כוח אדם – אנשי מפתח.

· קלטות גיבוי.

היבטים לצורך תכנון מערך גיבוי:

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

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

ג. תדירות עדכון הגיבוי.

ד. ניסוי תקופתי לבדיקת תקינות הגיבוי.

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

שיעור מס' 10

מעבדת IDEA

תוכנה לניתוח נתונים – CUST.

1. שלב תחקור – שיחות וראיונות שמטרתם להגיע לקבצים שיש לקלוט.

[הקבצים הזמינים לביקורת יהיו רלוונטיים לכל עבודת הביקורת]

2. קליטת הקבצים.

תהליך קליטת הקבצים

1. יש להוריד לצורך העבודה קובץ בשם Cpayment מהפורום (בפורום יש קובץ תרגילים ובו יש להוריד את קובץ ה- WORD שנקרא "תרגיל 2").

כאשר נקבל את ההודעה "לחץ כאן להורדה ..." יש ללחוץ על לחצן ימני על מנת לשמור את הקובץ בשם cpayment על הדיסקט (קובץ טקסט).

2. הכנת תשתית עבודה (לצורך ביצוע התרגיל) – יש ליצור ספריה חדשה בכונן C אשר נקראת winidea. בתוך ספריה זו ליצור תת ספריה בשם user . מתחת לספריה זו יש ליצור ספריה נוספת בשם sapakim.

את הקובץ cpayment יש להעתיק אל תוך ספריית sapakim.

אנו נלמד את העקרונות על קובץ המלאי וקובץ הנה"ח ונצטרך ליישם את העקרונות על הקובץ cpayment.

כניסה לתוכנה - בשולחן העבודה קיים אייקון של IDEA.

שלב קליטת הקובץ –

1. הגדרת ספריית עבודה –set working folder – file יש לעיין ולבחור במסלול המוביל לספריית sapakim (כלומר בוחרים ברמה אחת מעל הקובץ cpayment.

א. הגדרת שם לקוח – מס' ת.ז + שם מלא (באנגלית).

ב. שנה – 2001.

2. אשף קליטה – import assistant – file נפתחת מסך ובו ספריית העבודה שהוגדרה קודם. על ידי לחיצה על הכפתור עם שלושת הנקודות מגדירים איזה קבצים רוצים לקלוט, כלומר יש לבחור בקובץ cpayment.

· בשלב השני נפתח מסך שבו יש להגדיר איזה סוג קובץ – לא לגעת.

· בשלב הבא יש להגדיר את אורך הרשומה – לא לשנות.

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

· במסך הבא יש להגדיר את סוג השדה ושם השדה. לגבי התיאור – לא חובה.

שדה נומרי – NUMERIC שדה מספרי (סכום, כמות, יחידות משקל וכו').

שדה תאריכי – DATE – הפורמט של התאריך הוא YYYMMDD.

שדה אלפא נומרי – CHARACTER (אסמכתאות, מס' חשבוניות וכו').

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

· במסך האחרון נדרש לתת שם לבסיס הנתונים – מומלץ לשמור לפי אותו שם של הקובץ שקלטנו, כלומר cpayment.

ניתוח הנתונים

1. בדיקת כפילויות detection – duplicate key – data יש להגדיר על איזה שדה לרוץ על מנת לבדוק כפילויות. לצורך כך יש ללחוץ על הכפתור KEY. כאשר מדובר בחשבוניות ניתן לבדוק את שדה האסמכתא.

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

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

2. בדיקת רציפות gap detection – data ואז ללחוץ על character. לאחר מכן יש לסמן ב- field in use את השדה "אסמכתא". לאחר האישור נפתחת טבלה המראה איזה מס' אסמכתאות חסרים.

3. מיון – sort – data ולאחר מכן לסמן את השדה "אסמכתא". כך ניתן למצוא ביתר קלות את השדות החסרים ולדווח עליהם בדוח הביקורת.

4. שליפות – קיימות כמה אפשרויות שליפה: למסך (view) ולקובץ. השליפה היא לפי שאילתה.

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

לאחר מכן יש ללחוץ על התנאי שהפונקציה בודקת (<, >, = וכו').

על מנת לחזור ממסך השאילתה לקובץ המקור ניתן ללחוץ על האייקון X.

· שליפה לקובץ – extraction – data נפתח מסך שבו יש לתת שם לקובץ – בתרגיל יש לקרוא לקובץ ע"פ מס' הנדרש (נדרש 3, נדרש 4 וכו').

לחיצה על הציור של המחשב פותחת את המסך עם הפונקציות לצורך כתיבת השאילתה. לסיום יש ללחוץ על ה- V.

ניתן להגדיר אילו שדות בדיוק נרצה לקבל בקובץ של תוצאת השאילתה.

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

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

קיבוץ – field summarize – analysis ואז ללחוץ על key field. יש לבחור איזה שדה לסכום ולאחר מכן יש לבחור על פי איזה שדה לקבץ את הרשומות.לבסוף יש לתת שם לקובץ (בהתאם למס' נדרש).

קובץ התוצאות מראה כמה רשומות כללו את אותו שדה שלפיו התרחש הקיבוץ.

· ניתן לרבד ולקבץ לפי טווחים של סכומים.

Character – file stratification – analysis ברירת המחדל של התוכנה היא טווח של 10,000. כמו כן, ניתן להיכנס ולהקליד את הטווח הרצוי.

i. להגדיר קטגוריות.

ii. לזהות את השדה הנומרי שעל פיו יתבצע הריבוד.

iii. לסמן שם קובץ.

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

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

יש לרשום את מס' הימים לצורך בדיקת הגיל (חודש = 30 יום).

לבסוף יש לתת שם לקובץ ולאשר. ניתן לראות את הקובץ שנוצר.

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

על ידי לחיצה על append נפתח שדה נוסף.

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

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

השדה המדומה מסומן בצבע ורוד.

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

קובץ mlay (מלאי) שבו קיימים השדות asm, sum

קובץ hes (חשבונות) שבו קיימים שדות asm_hes, amount

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

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

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

מהלך של איחוד – join ניתן לאחד שתי טבלאות. תחילה יש לבחור בקובץ הראשי ולכן נניח שניגש תחילה לקובץ "חשבונות" הממוין (ברירת המחדל של התוכנה היא שהקובץ הראשון שנבחר הוא ה- primary).

Join databases – join ניתן לבחור איזה שדות מתוך קובץ חשבונות יופיעו בטבלה המאוחדת על ידי לחיצה על כפתור "field".

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

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

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

· מציג רק את הרשומות התואמות.

· רשומות שנמצאו בראשי ולא נמצאו במשני

· רשומות נמצאות במשני ולא בראשי.

· כל הרשומות של הראשי.

· כל הרשומות של שני הקבצים.

לבסוף יש לתת שם לקובץ.

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

החלק הראשון של התרגיל – ביצוע מס' שאילתות על קובץ בודד. לא לעשות סעיפים 6, 7 ו-13. החלק השני של התרגיל – פעולות על קבצים שונים. לא לעשות סעיף 9.

הנתיב אל הקבצים – C\program files\idea\samples

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

לבסוף יש להגיש דיסקט שבו מועתקים ספריות samples, cpayments.

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

תאריך ההגשה 13/1/02.

שיעור מס' 11

גל"ד 66 ונספחיו

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

"הנחיות ליישום תקני ביקורת בסביבת מ.מ.מ."

תקני הביקורת הם 5, 8, 9, 10.

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

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

דוגמא לנוהל ביקורת – ספירת מלאי – בא לאמת ספירה פיסית של המלאי.

אצל חברות מבוססות על מערכות מידע (כגון: YES, מת"ב וכו') יש בעיה עם נוכחות המבקר בעת אימות יתרות. לא ניתן ליישם את אותם נהלי הביקורת הרגילים.

הצורך בביקורת מערכות מידע היה קיים עוד לפני גל"ד 66.

ביקורת מ.מ.מ.

C A V R

שלמות דיוק תקפות הגבלת גישה

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

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

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

בקרות דיוק – חישוב מחדש של ריבית והפרשי הצמדה למשל, סיכומי אצווה, סיכומי סרק וכו'.

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

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

גל"ד נותן כמה הנחיות –

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

לפי גל"ד על רו"ח להבחין בין:

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

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

· בקרות ידניות – הבקרות שנעשות מחוץ למערכת.

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

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

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

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

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

דוגמא: מכירת שעון ללקוח דוד ב- 100 ₪.

רשומת מכירות מס' 2004.

חשבונית מס' 3005 על סך 100 ₪ כולל מע"מ. ביום המכירה

ת. משלוח מס' 3009 על סך 1 כמות שעון.

חישוב ריבית, אשראי והצמדה על סך 150 ₪ ללקוח דוד. עיבוד

קבלה מס' 7008 על סך 250 ₪. ביום התקבול

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

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

· העדר מערך מבדק פנימי נאות – בד"כ מערך מבדק פנימי מוודא שכל סוגי הבקרות פועלות (בקרות כלליות, בקרות יישומיות, בקרות ידניות).

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

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

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

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

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

נספחים לגל"ד 66

א. הבהרות בדבר מידע אודות מערכת המידע.

ב. מחשב אישי.

ג. סביבת און ליין.

ד. בסיסי נתונים.

ה. S'CAAT.

ו. לקט מונחים.

נספח א' – נושאים עליהם יש לאסוף מידע (לקראת תכנון הביקורת)

מדובר בשלב איסוף המידע בלבד – עדיין לא הביקורת עצמה.

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

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

1. מבנה ארגוני בסביבת מ.מ.מ.

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

2. חומרה ותוכנות –

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

· חומרה – רשימה של המחשבים, החיבורים, סוג השרת, סוג מערכת ההפעלה.

· תוכנת מערכת – גרסת מערכת ההפעלה, אנטי ווירוסים, תאריך התקנה וכו'.

· תוכנות יישומיות – אופיס, מנהל, חשבשבת וכו'.

3. נהלי פיתוח מערכות – בד"כ החברה מפתח בעצמה את המערכות. יש לבדוק -

· המתודולוגיה שבפיתוח המערכות, יוזם הפיתוח.

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

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

· בדיקת משתמש – בדיקה בסביבת TEST.

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

· עליה ל"חי" – עבודת המערכת בסביבת אמת.

4. גיבויים ושמירת מידע – יש לאסוף מידע על:

· אמצעי הגיבוי – קלטות, CD, רובוטים.

· המידע המגובה.

· אחראים על הגיבוי.

· צורות גיבוי – כל כמה זמן מתבצע גיבוי, איזה תקופת זמן מגובה אחורה.

5. שינויים צפויים ביישומים קיימים – יש לבדוק האם צפויים שינויים ממועד איסוף המידע ועד ביצוע הביקורת בפועל.

6. אבטחת מידע לוגית ופיסית –

· נוהלים קיימים.

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

· אמצעי אבטחה.

· מנהל אבטחת מידע – מומלץ לדבר עם מנהל אבטחת המידע בשלב איסוף המידע.

7. תוכנית התאוששות מאסון –

· DRP (תוכנית התאוששות מאסון) – Disaster Rrecovery Plan

· BCP (המשכיות העסק החי) – Business Continuity Plan

נספח ב' – מחשבים אישיים

בנספח קיימת הבחנה בין שלושה סוגים של מחשבים אישיים:

1. תחנת עבודה בודדת בשימוש משתמש יחיד באותו זמן.

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

3. תחנת עבודה המחוברת למחשב מרכזי.

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

המבקר יכול לדרוש הוספה של בקרות –

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

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

3. אבטחת תוכנה ונתונים – ארגון הקבצים בספריות, סיסמאות והצפנה.

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

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

CR * DR * IR = AR

הסיכון שבמהות הוא נתון קבוע.

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

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

נספח ג' – מערכת מקוונת (און ליין)

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

המסופים יכולים להיות "חכמים" או "טיפשים".

מחשב "טיפש" – מחשב שלא מבצע שום עיבוד בעצמו (המעבד מצוי בשרת).

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

סיווג מערכות מקוונות –

1. עיבוד בזמן אמיתי (real time) – באותו רגע שבו מוזן הנתון מתעדכנת הרשומה הרלוונטית במחשב המרכזי.

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

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

2. עיבוד אצווה ( batch) – עדכון הרשומה במחשב המרכזי מתבצעת מאוחר יותר מרגע הזנת הנתון. בסוג עיבוד שכזה ניתן לנהל את סדר העיבודים.

חיסרון – לא ניתן לקבל משוב מיידי על שגיאות.

3. עיבוד זיכרון (memo update) – לא נהוג יותר היום.

4. שאילתות – שליפת הנתונים מתוך המאגר.

5. עיבוד בפריקה ( downloading) – לא נהוג יותר היום.

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

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

· בדיקות על סבירות ותקפות

· בקרה על קבצים

סיכום אצווה – סיכום מס' הרשומות, סיכום סכומי החשבוניות. אותו סיכום ילווה את האצווה ובמעבר למחשב המרכזי מתבצעת בדיקה על אותם סיכומים.

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

נספח ד' – מערכות בסיסי נתונים

מערכת בסיס נתונים - אוסף נתונים בו משתמשים מס' משתמשים לשימושים שונים במשותף.

בד"כ מערכת בסיס הנתונים מורכבת מ –

1. בסיס הנתונים – טבלאות הנתונים

2. DBMS - Data Base Management System- מערכת האחראית על תחזוקה והפעלה של בסיס הנתונים. המערכת כוללת הרשאות לטבלאות מסוימות, גישה ליישומים מסוימים.

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

1. שיתוף נתונים – מתבצע בין משתמשים לבין תוכניות.

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

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

בקרה פנימית בסביבת בסיס נתונים

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

יש להבטיח את גישה אל בסיס הנתונים (סיסמאות, הרשאות וכו')

שיעור מס' 12

מחזור חיים של מערכת מידע ממוחשבת

				פיתוח
	יישום

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

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

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

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

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

שלב הייזום -

המניעים לשלב הייזום:

· שינויים טכנולוגיים (למשל מעבר מ- DOS ל- WINDOWS). כלים ישנים לא נתמכים ע"י ספקים חיצוניים ונוצרת בעיה של עלות.

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

· סיבות אחרות – ספק התוכנה פשט את הרגל, אין מי שיתמוך בארגון וחייבים להחליף את המערכת, מעבר לשנת 2000 וכו'

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

ברגע שההנהלה הסכימה להחליף את המערכת עוברים לשלב הבא –

חקר הישימות –

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

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

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

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

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

הגדרת דרישות – יש לקבוע מהן הדרישות מהמערכת החדשה.

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

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

[לעיתים מבצעים חלק מהשלבים במקביל והחלוקה שמצוינת לעיל היא החלוקה המסורתית]

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

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

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

3. מיקור חוץ (OUT SOURCING) – מוסרים את האחריות להפעלת המערכת לצד שלישי. מבחינת המשתמש אין זה משנה היכן יושבת המערכת.

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

יתרונות וחסרונות -

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

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

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

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

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

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

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

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

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

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

נשאלת השאלה – איך סוג פתרון זה משפיע על השלבים הבאים?

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

שלב הפיתוח -

שלב זה מתחלק ל- 3 חלקים:

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

2. עיצוב – שלב ביניים שקובע איך יראה הממשק למשתמש, כלומר איך יראו ויזואלית הדברים. תחילה יש לבחור את כלי הפיתוח (access, visual basic). רק לאחר מכן מחליטים כיצד ייראה הממשק למשתמש – זהו התהליך הכי ארוך, שאורך שנה או שנתיים ויש בו הכי הרבה סיכונים.

3. שלב התכנות עצמו.

שלב היישום

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

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

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

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

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

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

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

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

בדיקות קבלה -

הרעיון הוא לבדוק לגבי כל דרישה – האם היא פועלת כראוי.

בשלב הפיתוח עובדים על סביבת פיתוח ובשלב הבדיקות עובדים על סביבת ה- TEST. על מנת לבדוק האם המערכת עובדת כמו שצריך, הבדיקה נעשית על ידי המשתמשים (ATP).

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

[בד"כ מתעוררות תקלות אולם אם הגענו למינימום תקלות ניתן לקבל את התוכנה. מספיק ש- 90% עבר את הבדיקות וכל השאר יטופלו תוך כדי העבודה השוטפת]

Test data – בדיקת מצבים שגרתיים ולא שגרתיים.

הדרכה והטמעה –

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

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

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

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

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

הפעלה –

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

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

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

תחזוקה –

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

מדובר בשלב שאורך בין 7 – 5 שנים כאשר לאחר מכן בד"כ מחליפים שוב את המערכת.

תפקיד המבקר החיצוני (מבקר מ.מ.מ) בכל שלב

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

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

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

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

[מבקר החשבונות בודק בעיקר לו"ז ועלויות – פחות מעמיק]

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

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

7. תחזוקה – בשלב זה המבקר מבצע את כל הבדיקות שלו.

[כאמור שלב זה אורך בין 7 – 5 שנים וכל שאר השלבים אורכים 2 – 1 שנים]

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

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

שאלת קיף 99 – ERP

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

לפני ה- ERP היו מערכות שנתנו מענה רק לחלק מהדרישות.

מערכת ה- ERP היא מערכת לניהול כולל, התומכת גם בשנת 2000 בניגוד לשאר המערכות הקיימות.

תהליך החלפת המערכת החל ב- 10/97 – שלב היישום אשר אמור היה להסתיים ב- 9/99 – שלב ההפעלה.

נדרש:

1. בעבר לא נבדקו מ.מ.מ. (ביקורת ניהול ייצור) במעבר ל- ERP האם צריך לבדוק?
הייצור משפיע על סעיפי המלאי ועלות המכר. יש מקום לחשבונאות ניהולית – מעקב אחר סטיות. מדובר בחברה יצרנית וזה מהותי לגביה, על כן מדברים על מערכת ERP, עובדים על data base אחד והכל קשור לכל.

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

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

· ההסכם עם הספק – האם הוא עונה על הדרישות.

· אבטחת מידע.

· מידת התלות בספק.

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

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

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

למבחן

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

שאלה ראשונה – שאלת אירוע – ניתוח של מצב בחברה.

שאלה שניה – שאלה על גילוי הדעת (גל"ד 66 כולל נספחים).

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

שיעור מס' 13

מסחר אלקטרוני

מדובר בסביבה מיוחדת הנבדלת מעט מסביבה ממוחשבת רגילה (מבחינת היבטי אבטחה, אוטנטיות וכו').

קיימת הצעה לנספח חדש לגל"ד 66 – עסקאות סחר אלקטרוני

רשת אינטרנט מושגים כלליים –

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

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

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

הרשת מתבססת על IP – פרוטוקול אינטרנט. על מנת להתחבר לרשת האינטרנט נדרש לקבל חיבור מאחד מספקי האינטרנט. לאחר החיבור לספק מקבלים כתובת ייחודית (IP) ודף בית ע"פ דרישת המשתמש.

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

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

האינטרנט מציע מס' שירותים:

1. שירותי סחר אלקטרוני – B2B, C2B, M2M וכו'.

2. דואר אלקטרוני.

3. קבוצות דיון – פורומים, חדשות, צ'טים.

4. אחזור מידע – גישה למאגרי מידע.

יתרונות:

· גישה נוחה למידע, זמינה

· גישה לפלח שוק רחב

· איסוף מידע עסקי

· חיסכון בעלויות

· שיפור תחזוקה וקשר עם לקוחות

סיכונים:

· נספח ג' לגל"ד 66 מדבר על סביבה מקוונת וסיכוניה.

· חדירה למאגרי מידע

· התחזות

· ציטוט

· וירוסים

· שלמות המידע בתווך הציבורי

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

· היעדר מסמכי מקור

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

· שינוי מסמכי מקור על ידי המבוקר

· התכחשות לעסקה

· פגיעה תדמיתית – אנשים שמחבלים או פורצים את המערכת פוגעים בתדמית

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

בקרות פנימיות בסביבת סחר אלקטרוני:

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

סיסמאות – הגנה על קבצי הסיסמאות וכו'.

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

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

· הצפנות – למניעת ציטוטים וכו'.

· חתימות אלקטרוניות ושיטות זיהוי מתקדמות

· צמצום נקודות גישה

סוגי מערכות מידע בסביבת האינטרנט

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

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

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

נהלי הביקורת בחברה המנהלת סחר אלקטרוני:

1. אבטחת מידע –

(א) קיום מדיניות

(ב) נהלים

(ג) הרשאות גישה

(ד) סיסמאות

(ה) גישה מרחוק

(ו) תיעוד יומן אירועים

(ז) התאוששות

(ח) אבטחה פיסית

(ט) אבטחת תקשורת

(י) הצפנה

(יא) קיומם של אמצעי בקרה וזיהוי מתאימים

(יב) כלי הגנה מתאימים (FW)

(יג) התרעה על ניסיונות פריצה וחדירה (Intrusion Detection)

2. קשרים וממשקים עם המערכות השונות (סוג הקשר, רמת הסיווג מבחינת סיכונים וכו').

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

4. התאמה להוראות החוק בעיקר הוראות מס הכנסה, מע"מ, תזמון האירועים (הממשקים) ועיתוי ההכרה בהכנסות/הוצאות.

שאלת בחינה – שאלה 11 חורף 98

בנק מסחרי בעל 100 סניפים. בשנת 98 הוחלט:

1. החלפת כל מערכת המחשב המרכזית (חומרה, תשתית, תוכנה, יישומים וכו').

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

נדרש 1 –

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

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

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

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

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

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

1. עריכת הביקורת השוטפת במערכת הקיימת תוך התחשבות בהחלטה להחליף את המערכות הקיימות. רכיבים שעתידים להתחלף בזמן הקרוב – אין טעם לבדוק אותם אולם ככל שמתקדמים בשלב מחזור החיים של המערכת החדשה (הטמעה, בדיקות קבלה) כך המבקר יקדיש יותר משאבי ביקורת למערכת החדשה ולהיפך...

2. בחינת הצורך בהחלפת המערכות.

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

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

5. השתתפות בוועדות ההיגוי של הפרויקט והעברת ביקורת.

נדרש 2 –

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

עומדים לבצע שינויים בסניפים (LAN) ולפיכך -

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

נדרש 3 –

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

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

יתרונות:

1. הכנת ביקורת מ.מ.מ. תוך התייחסות להיבטי חשבונאות עפ"י צרכי המבקר החיצוני (התרכזות במערכות החשבונאיות, דיוק, שלמות וכו').

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

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

4. הוספת אלמנט ביקורת נוסף.

נדרש 4 –

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

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

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

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

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

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

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

שאלת בחינה – שאלה 6 קיץ 97

הנה"ח

ממשק ממשק

אוטומטי ידני

כל המערכות "מדברות" עם מחשב מרכזי אחד (שבו מתנהל בסיס הנתונים).

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

נדרש א' –

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

1. ניתן להעלות את רמת המהימנות באמצעות שימוש יעיל באמצעים הכלולים ב- DBMS (מערכת ניהול בסיסי הנתונים) – פונקציות התאוששות, בדיקת תבניות הטבלאות.

2. הפקת דוחות באמצעות מחוללי דוחות מוכנים ב- DBMS (בדומה לאקסס).

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

נדרש ב' –

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

נדרש ג' –

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

גל"ד נספח ה' – טכניקות ביקורת ונדרש לפרט מהן טכניקות הביקורת הרלוונטיות למקרה זה:

ITF, TEST DATA וכו'.

נדרש ד' –

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

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

יתרונות:

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

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

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

חסרונות:

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

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

· בדיקת תקינות יחידת הדמה.

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

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

הערה: סעיף 4 לגל"ד 66 – קובע את התחולה של ביקורת ענ"א. מדובר בסעיף בעייתי משום שהסעיף מאפשר למבקר לבצע נהלים חלופיים ולא לבצע ביקורת ענ"א (הסיבה לכך היא לאפשר למשרדים הקטנים לקבל על עצמם תיקים גדולים למרות שאין להם את התשתית לביקורת ענ"א).

בשאלות שבהן נדרשים לקבוע האם יש לבצע ביקורת ענ"א אזי יש לדבר על הסעיף הנ"ל.

למבחן –

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

מומלץ לחלק את הזמן בצורה חכמה ולא להקדיש לשאלה הראשונה יותר מדי זמן.

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

שאלה שלישית – 30 נקודות על גילוי הדעת.