hebat garda cilik!!!!!
Rabu, 18 November 2009
Work Breakdown Structure
A work breakdown structure (WBS) in project management and systems engineering, is a tool used to define and group a project's discrete work elements (or tasks) in a way that helps organize and define the total work scope of the project[1].
A work breakdown structure element may be a product, data, a service, or any combination. A WBS also provides the necessary framework for detailed cost estimating and control along with providing guidance for schedule development and control. Additionally the WBS is a dynamic tool and can be revised and updated as needed by the project manager.[1]
Contents
Overview
Example of Work breakdown structure applied in a NASA reporting structure.[2]
The Work Breakdown Structure is a tree structure, which shows a subdivision of effort required to achieve an objective; for example a program, project, and contract. In a project or contract, the WBS is developed by starting with[2] :
* the end objective and
* successively subdividing it into manageable components
* in terms of size, duration, and responsibility (e.g., systems, subsystems, components, tasks, subtasks, and work packages)
* which include all steps necessary to achieve the objective.
The Work Breakdown Structure provides a common framework for the natural development of the overall planning and control of a contract and is the basis for dividing work into definable increments from which the statement of work can be developed and technical, schedule, cost, and labor hour reporting can be established.[2]
A work breakdown structure permits summing of subordinate costs for tasks, materials, etc., into their successively higher level “parent” tasks, materials, etc. For each element of the work breakdown structure, a description of the task to be performed is generated. [3] This technique (sometimes called a System Breakdown Structure [4]) is used to define and organize the total scope of a project.
The WBS is organized around the primary products of the project (or planned outcomes) instead of the work needed to produce the products (planned actions). Since the planned outcomes are the desired ends of the project, they form a relatively stable set of categories in which the costs of the planned actions needed to achieve them can be collected. A well-designed WBS makes it easy to assign each project activity to one and only one terminal element of the WBS. In addition to its function in cost accounting, the WBS also helps map requirements from one level of system specification to another, for example a requirements cross reference matrix mapping functional requirements to high level or low level design documents.
[edit] History
The concept of Work Breakdown Structure developed with the Program Evaluation and Review Technique (PERT) in the United States Department of Defense (DoD). PERT was introduced by the U.S. Navy in 1957 to support the development of its Polaris missile program. [1] While the term "work breakdown structure" was not used, this first implementation of PERT did organize the tasks into product-oriented categories.[5]
By June 1962, DoD, NASA and the aerospace industry published a document for the PERT/COST system which described the WBS approach. [6] This guide was endorsed by the Secretary of Defense for adoption by all services.[7] In 1968, the DoD issued "Work Breakdown Structures for Defense Materiel Items" (MIL-STD-881), a military standard requiring the use of work breakdown structures across the DoD. [8] This standard established top-level templates for common defense materiel items along with associated descriptions (WBS dictionary) for their elements.
The document has been revised several times, most recently in 2005. The current version of this document can be found in "Work Breakdown Structures for Defense Materiel Items" (MIL-HDBK-881A).[9] It includes instructions for preparing work breakdown structures, templates for the top three levels of typical systems, and a set of "common elements" that are applicable to all major systems and subsystems.
Example from MIL-HDBK-881, which illustrates the first three levels of typical system architectures. [10]
Defense Materiel Item categories from MIL-HDBK-881A:
* Aircraft Systems
* Electronic/Automated Software Systems
* Missile Systems
* Ordnance Systems
* Sea Systems
* Space Systems
* Surface Vehicle Systems
* Unmanned Air Vehicle Systems
* Common Elements
The common elements identified in MIL-HDBK-881A, Appendix I are: Integration, assembly, test, and checkout; Systems engineering; Program management; Training; Data; System test and evaluation; Peculiar support equipment; Common support equipment; Operational and site activation; Industrial facilities; and Initial spares and repair parts
In 1987, the Project Management Institute (PMI) documented the expansion of these techniques across non-defense organizations. The Project Management Body of Knowledge (PMBOK) Guide provides an overview of the WBS concept, while the "Practice Standard for Work Breakdown Structures" is comparable to the DoD handbook, but is intended for more general application.[11]
[edit] WBS design principles
This section contains too much jargon and may need simplification or further explanation. Please discuss this issue on the talk page, and/or remove or explain jargon terms used in the article. Editing help is available. (September 2008)
The 100% rule
One of the most important Work Breakdown Structure design principles is called the 100% Rule [12]. It has been defined as follows:
The 100% Rule...states that the WBS includes 100% of the work defined by the project scope and captures all deliverables – internal, external, interim – in terms of the work to be completed, including project management. The 100% rule is one of the most important principles guiding the development, decomposition and evaluation of the WBS. The rule applies at all levels within the hierarchy: the sum of the work at the “child” level must equal 100% of the work represented by the “parent” and the WBS should not include any work that falls outside the actual scope of the project, that is, it cannot include more than 100% of the work… It is important to remember that the 100% rule also applies to the activity level. The work represented by the activities in each work package must add up to 100% of the work necessary to complete the work package. [13]
Mutually exclusive elements
Mutually exclusive: In addition to the 100% Rule, it is important that there is no overlap in scope definition between two elements of a Work Breakdown Structure. This ambiguity could result in duplicated work or mis-communications about responsibility and authority. Likewise, such overlap is likely to cause confusion regarding project cost accounting. If the WBS element names are ambiguous, a WBS dictionary can help clarify the distinctions between WBS elements. The WBS Dictionary describes each component of the WBS with milestones, deliverables, activities, scope, and sometimes dates, resources, costs, quality.
Planned outcomes, not planned actions
If the Work Breakdown Structure designer attempts to capture any action-oriented details in the WBS, he/she will likely include either too many actions or too few actions. Too many actions will exceed 100% of the parent's scope and too few will fall short of 100% of the parent's scope. The best way to adhere to the 100% Rule is to define WBS elements in terms of outcomes or results. This also ensures that the WBS is not overly prescriptive of methods, allowing for greater ingenuity and creative thinking on the part of the project participants. For new product development projects, the most common technique to ensure an outcome-oriented WBS is to use a product breakdown structure. Feature-driven software projects may use a similar technique which is to employ a feature breakdown structure. When a project provides professional services, a common technique is to capture all planned deliverables to create a deliverable-oriented WBS. Work breakdown structures that subdivide work by project phases (e.g. Preliminary Design Phase, Critical Design Phase) must ensure that phases are clearly separated by a deliverable also used in defining Entry and Exit Criteria (e.g. an approved Preliminary Design Review document, or an approved Critical Design Review document).
Level of detail
A question to be answered in determining the duration of activities necessary to produce a deliverable defined by the WBS is when to stop dividing work into smaller elements. There are several heuristics or "rules of thumb" used when determining the appropriate duration of an activity or group of activities necessary to produce a specific deliverable defined by the WBS.
* The first is the "80 hour rule" which means that no single activity or group of activities to produce a single deliverable should be more than 80 hours of effort.
* The second rule of thumb is that no activity or series of activities should be longer than a single reporting period. Thus if the project team is reporting progress monthly, then no single activity or series of activities should be longer than one month long.
* The last heuristic is the "if it makes sense" rule. Applying this rule of thumb, one can apply "common sense" when creating the duration of a single activity or group of activities necessary to produce a deliverable defined by the WBS.
A work package at the activity level is a task that:
* can be realistically and confidently estimated;
* makes no sense practically to break down any further;
* can be completed in accordance with one of the heuristics defined above;
* produces a deliverable which is measurable; and
* forms a unique package of work which can be outsourced or contracted out.
WBS coding scheme
It is common for Work Breakdown Structure elements to be numbered sequentially to reveal the hierarchical structure. For example 1.3.2 Rear Wheel identifies this item as a Level 3 WBS element, since there are three numbers separated by a decimal point. A coding scheme also helps WBS elements to be recognized in any written context[14].
A practical example of the WBS coding scheme is[15]:
1267.1 Systems Integration
1267.1.1 Requirements Definition
1267.1.2 Regulations
1267.1.3 Scheduling
1267.1.4 Monitoring & Control
1267.1.5 Procurement Management
1267.1.6 Closeout
1267.2 Design
1267.2.1 Conceptual Design
1267.2.2 Preliminary Design
1267.2.3 Final Design
Terminal element
A terminal element is the lowest element (activity or deliverable) in a work breakdown structure; it is not further subdivided. Terminal elements are the items that are estimated in terms of resource requirements, budget and duration; linked by dependencies; and scheduled. A terminal element is sometimes called a work package, although the two terms are not synonymous.
Example
The WBS Construction Technique employing the 100% Rule during WBS construction.
The figure (on the right) shows a Work Breakdown Structure construction technique that demonstrates the 100% Rule and the "progressive elaboration" technique. At WBS Level 1 it shows 100 units of work as the total scope of a project to design and build a custom bicycle. At WBS Level 2, the 100 units are divided into seven elements. The number of units allocated to each element of work can be based on effort or cost; it is not an estimate of task duration.
The three largest elements of WBS Level 2 are further subdivided at Level 3. The two largest elements at Level 3 each represent only 17% of the total scope of the project. These larger elements could be further subdivided using the progressive elaboration technique described above.
WBS design can be supported by software (e.g. a spreadsheet) to allow automatic rolling up of point values. Estimates of effort or cost can be developed through discussions among project team members. This collaborative technique builds greater insight into scope definitions, underlying assumptions, and consensus regarding the level of granularity required to manage the project.
A work breakdown structure element may be a product, data, a service, or any combination. A WBS also provides the necessary framework for detailed cost estimating and control along with providing guidance for schedule development and control. Additionally the WBS is a dynamic tool and can be revised and updated as needed by the project manager.[1]
Contents
Overview
Example of Work breakdown structure applied in a NASA reporting structure.[2]
The Work Breakdown Structure is a tree structure, which shows a subdivision of effort required to achieve an objective; for example a program, project, and contract. In a project or contract, the WBS is developed by starting with[2] :
* the end objective and
* successively subdividing it into manageable components
* in terms of size, duration, and responsibility (e.g., systems, subsystems, components, tasks, subtasks, and work packages)
* which include all steps necessary to achieve the objective.
The Work Breakdown Structure provides a common framework for the natural development of the overall planning and control of a contract and is the basis for dividing work into definable increments from which the statement of work can be developed and technical, schedule, cost, and labor hour reporting can be established.[2]
A work breakdown structure permits summing of subordinate costs for tasks, materials, etc., into their successively higher level “parent” tasks, materials, etc. For each element of the work breakdown structure, a description of the task to be performed is generated. [3] This technique (sometimes called a System Breakdown Structure [4]) is used to define and organize the total scope of a project.
The WBS is organized around the primary products of the project (or planned outcomes) instead of the work needed to produce the products (planned actions). Since the planned outcomes are the desired ends of the project, they form a relatively stable set of categories in which the costs of the planned actions needed to achieve them can be collected. A well-designed WBS makes it easy to assign each project activity to one and only one terminal element of the WBS. In addition to its function in cost accounting, the WBS also helps map requirements from one level of system specification to another, for example a requirements cross reference matrix mapping functional requirements to high level or low level design documents.
[edit] History
The concept of Work Breakdown Structure developed with the Program Evaluation and Review Technique (PERT) in the United States Department of Defense (DoD). PERT was introduced by the U.S. Navy in 1957 to support the development of its Polaris missile program. [1] While the term "work breakdown structure" was not used, this first implementation of PERT did organize the tasks into product-oriented categories.[5]
By June 1962, DoD, NASA and the aerospace industry published a document for the PERT/COST system which described the WBS approach. [6] This guide was endorsed by the Secretary of Defense for adoption by all services.[7] In 1968, the DoD issued "Work Breakdown Structures for Defense Materiel Items" (MIL-STD-881), a military standard requiring the use of work breakdown structures across the DoD. [8] This standard established top-level templates for common defense materiel items along with associated descriptions (WBS dictionary) for their elements.
The document has been revised several times, most recently in 2005. The current version of this document can be found in "Work Breakdown Structures for Defense Materiel Items" (MIL-HDBK-881A).[9] It includes instructions for preparing work breakdown structures, templates for the top three levels of typical systems, and a set of "common elements" that are applicable to all major systems and subsystems.
Example from MIL-HDBK-881, which illustrates the first three levels of typical system architectures. [10]
Defense Materiel Item categories from MIL-HDBK-881A:
* Aircraft Systems
* Electronic/Automated Software Systems
* Missile Systems
* Ordnance Systems
* Sea Systems
* Space Systems
* Surface Vehicle Systems
* Unmanned Air Vehicle Systems
* Common Elements
The common elements identified in MIL-HDBK-881A, Appendix I are: Integration, assembly, test, and checkout; Systems engineering; Program management; Training; Data; System test and evaluation; Peculiar support equipment; Common support equipment; Operational and site activation; Industrial facilities; and Initial spares and repair parts
In 1987, the Project Management Institute (PMI) documented the expansion of these techniques across non-defense organizations. The Project Management Body of Knowledge (PMBOK) Guide provides an overview of the WBS concept, while the "Practice Standard for Work Breakdown Structures" is comparable to the DoD handbook, but is intended for more general application.[11]
[edit] WBS design principles
This section contains too much jargon and may need simplification or further explanation. Please discuss this issue on the talk page, and/or remove or explain jargon terms used in the article. Editing help is available. (September 2008)
The 100% rule
One of the most important Work Breakdown Structure design principles is called the 100% Rule [12]. It has been defined as follows:
The 100% Rule...states that the WBS includes 100% of the work defined by the project scope and captures all deliverables – internal, external, interim – in terms of the work to be completed, including project management. The 100% rule is one of the most important principles guiding the development, decomposition and evaluation of the WBS. The rule applies at all levels within the hierarchy: the sum of the work at the “child” level must equal 100% of the work represented by the “parent” and the WBS should not include any work that falls outside the actual scope of the project, that is, it cannot include more than 100% of the work… It is important to remember that the 100% rule also applies to the activity level. The work represented by the activities in each work package must add up to 100% of the work necessary to complete the work package. [13]
Mutually exclusive elements
Mutually exclusive: In addition to the 100% Rule, it is important that there is no overlap in scope definition between two elements of a Work Breakdown Structure. This ambiguity could result in duplicated work or mis-communications about responsibility and authority. Likewise, such overlap is likely to cause confusion regarding project cost accounting. If the WBS element names are ambiguous, a WBS dictionary can help clarify the distinctions between WBS elements. The WBS Dictionary describes each component of the WBS with milestones, deliverables, activities, scope, and sometimes dates, resources, costs, quality.
Planned outcomes, not planned actions
If the Work Breakdown Structure designer attempts to capture any action-oriented details in the WBS, he/she will likely include either too many actions or too few actions. Too many actions will exceed 100% of the parent's scope and too few will fall short of 100% of the parent's scope. The best way to adhere to the 100% Rule is to define WBS elements in terms of outcomes or results. This also ensures that the WBS is not overly prescriptive of methods, allowing for greater ingenuity and creative thinking on the part of the project participants. For new product development projects, the most common technique to ensure an outcome-oriented WBS is to use a product breakdown structure. Feature-driven software projects may use a similar technique which is to employ a feature breakdown structure. When a project provides professional services, a common technique is to capture all planned deliverables to create a deliverable-oriented WBS. Work breakdown structures that subdivide work by project phases (e.g. Preliminary Design Phase, Critical Design Phase) must ensure that phases are clearly separated by a deliverable also used in defining Entry and Exit Criteria (e.g. an approved Preliminary Design Review document, or an approved Critical Design Review document).
Level of detail
A question to be answered in determining the duration of activities necessary to produce a deliverable defined by the WBS is when to stop dividing work into smaller elements. There are several heuristics or "rules of thumb" used when determining the appropriate duration of an activity or group of activities necessary to produce a specific deliverable defined by the WBS.
* The first is the "80 hour rule" which means that no single activity or group of activities to produce a single deliverable should be more than 80 hours of effort.
* The second rule of thumb is that no activity or series of activities should be longer than a single reporting period. Thus if the project team is reporting progress monthly, then no single activity or series of activities should be longer than one month long.
* The last heuristic is the "if it makes sense" rule. Applying this rule of thumb, one can apply "common sense" when creating the duration of a single activity or group of activities necessary to produce a deliverable defined by the WBS.
A work package at the activity level is a task that:
* can be realistically and confidently estimated;
* makes no sense practically to break down any further;
* can be completed in accordance with one of the heuristics defined above;
* produces a deliverable which is measurable; and
* forms a unique package of work which can be outsourced or contracted out.
WBS coding scheme
It is common for Work Breakdown Structure elements to be numbered sequentially to reveal the hierarchical structure. For example 1.3.2 Rear Wheel identifies this item as a Level 3 WBS element, since there are three numbers separated by a decimal point. A coding scheme also helps WBS elements to be recognized in any written context[14].
A practical example of the WBS coding scheme is[15]:
1267.1 Systems Integration
1267.1.1 Requirements Definition
1267.1.2 Regulations
1267.1.3 Scheduling
1267.1.4 Monitoring & Control
1267.1.5 Procurement Management
1267.1.6 Closeout
1267.2 Design
1267.2.1 Conceptual Design
1267.2.2 Preliminary Design
1267.2.3 Final Design
Terminal element
A terminal element is the lowest element (activity or deliverable) in a work breakdown structure; it is not further subdivided. Terminal elements are the items that are estimated in terms of resource requirements, budget and duration; linked by dependencies; and scheduled. A terminal element is sometimes called a work package, although the two terms are not synonymous.
Example
The WBS Construction Technique employing the 100% Rule during WBS construction.
The figure (on the right) shows a Work Breakdown Structure construction technique that demonstrates the 100% Rule and the "progressive elaboration" technique. At WBS Level 1 it shows 100 units of work as the total scope of a project to design and build a custom bicycle. At WBS Level 2, the 100 units are divided into seven elements. The number of units allocated to each element of work can be based on effort or cost; it is not an estimate of task duration.
The three largest elements of WBS Level 2 are further subdivided at Level 3. The two largest elements at Level 3 each represent only 17% of the total scope of the project. These larger elements could be further subdivided using the progressive elaboration technique described above.
WBS design can be supported by software (e.g. a spreadsheet) to allow automatic rolling up of point values. Estimates of effort or cost can be developed through discussions among project team members. This collaborative technique builds greater insight into scope definitions, underlying assumptions, and consensus regarding the level of granularity required to manage the project.
MANAJEMEN RISIKO TEKNOLOGI INFORMASI “
1. Pengendalian Umum
Tujuan dari pengendalian umum yaitu untuk mencegah orang yang tidak terotorisasi mengakses sistem dan untuk meyakini bahwa hanya transaksi yang terotorisasi dan data yang valid di input dalam terminal.
Metode Pengendalian Umum :
1. Pembatasan akses phisik ke terminal (hanya operator yang terotorisasi ).
2. Metode identifikasi terminal dan operator seperti password (hanya terminal dan user terotorisasi yang dapat akses pada sistem).
3. Proteksi data dari fragmentasi, intermixing dan encryption (mencegah unotorisasi tambahan atau charges selama transmisi data).
4. Perancangan skedul formal otorisasi bagi user.
2. Pengendalian Aplikasi
Adapun tujuan dari pengendalian aplikasi sebagai berikut :
1. Tujuan Preventive yaitu untuk meyakini transaksi yang di input adalah reliable, proper, otorisasi dan valid.
Pengendalian aplikasi pada input transaksi on-line harus ada prosedur tertulis yang memberikan pedoman bagi operator terminal dan assistant untuk mengurangi kemungkinan kesalahan. Prosedur tertulis seharusnya
mencakup operasi dari terminal misal prosedur aplikasi yang terkait untuk referensi dari file, input dari transaksi dan parameter data koreksi dari keying error, dan withdrawal dari transaksi untuk kesalahan sumber.
2. Tujuan Deteksi untuk meyakini bahwa data entry unreliable dan improper terdeteksi. Pengendalian aplikasi untuk mendeteksi kesalahan entry transaksi on-line termasuk dalam pengendalian batch dan test validasi.
3. Tujuan Koreksi untuk menyakini data entri unreliable dan improper telah dikoreksi. Pengendalian koreksi
kesalahan dari data entri harus langsung sebab masingmasing transaksi dikoreksi secara individual.
II. RISIKO KESALAHAN PROSES
Pemrosesan adalah fungsi dalam komputer yaitu operasi data (validasi data, kalkulasi , komparasi, penjumlahan, update file, maintenace file, sequencing, inquiry dan koreksi kesalahan) dengan instruksi program.
Risiko dari operasi pemrosesan sebagai berikut :
1. Kesalahan record yang dipakai dalam pemrosesan.
2. Kesalahan file yang digunakan dalam pemrosesan
3. Kesalahan operator memasukan data pada computer console
4. Kesalahan table value yang digunakan dalam pemrosesan
5. Kesalahan default value yang digunakan dalam pemrosesan
6. Kesalahan dalam pemrosesan akibat salah versi pada program.
7. Kesalahan dalam data input yang digunakan dalam pemrosesan tidak valid.
8. Data input tidak diotorisasi user saat pemrosesan
9. Kesalahan hasil akibat perhitungan yang tidak benar.
10. Kesalahan hasil akibat kesalahan logika pemrosesan.
11. Transaksi yang otomatis (dijalankan selama proses) tidak disertai kebijakan manajemen.
Risiko–risiko tersebut dapat dikurangi dengan menggunakan pengendalian umum dan pengendalian aplikasi.
1. Tujuan Preventive yaitu meyakini bahwa pemrosesan adalah reliable, proper dan terotorisasi.
Pengendalian umum dan pengendalian input berfungsi untuk mencegah kesalahan (data, program atau file) dalam pemrosesan sedangkan pengendalian pemrosesan digunakan untuk mendeteksi kesalahan. Pengendalian umum membuat lingkungan pemrosesan kondusif dan program aplikasi dan data (file) yang digunakan adalah benar.
Pengendalian input meyakinkan bahwa data yang digunakan dalam pemrosesan adalah reliable, proper dan terotorisasi. Untuk meyakini kebenaran logika program, proper dan lengkap dengan pengendalian umum yaitu :
1. Pengendalian pengembangan sistem menyakini bahwa program ditulis properly.
2. Praktek kepegawaian meyakini bahwa pengembangan sistem dan program dilakukan oleh personel yang kompenten.
3. Pengendalian library, pengendalian akses dan rotasi perkerjaan mengurangi peluang perubahan unotorisasi terhadap program aplikasi.
4. Pengendalian perubahan program dan pengendalian library meyakini bahwa hasil program adalah terotorisasi versi dari program. Prosedur recovery meyakini bahwa program untuk tujuan back up adalah versi terakhir .
Untuk mencegah penggunaan file yang tidak benar dengan pengendalian sebagai berikut yaitu:
a. Pengendalian library termasuk fungsi librarian untuk meyakini file yang proper untuk operasi, seperti pengendalian phisik atas penggunaan file, pelabelan file ekternal dan internal, proteksi file dari kerusakan phisik selama digunakan.
b. Pengendalian Prosedur operasi standar (SOP) dan dokumentasi operasi meyakini bahwa operator membaca label eksternal, cek console message dan lainnya serta mengurangi penggunaan file yang salah.
2. Tujuan deteksi adalah meyakini bahwa unrealible, improper dan unotorisasi proses terdeteksi.
Pengendalian umum yang kuat (pada pengembangan sistem dan dokumentasi) membantu meyakini bahwa program ditulis dengan benar. Pengujian menjadi penting pada sistem yang komplek dan adanya perubahan-
perubahan. Sistem yang komplek membuat kesulitan dalam mengantisipasi test posible logical alternative atau kombinasi alternatif sehingga menimbulkan konskwensi kesalahan dalam program tidak terprediksi selama pemrosesan. Sebagai contoh kesalahan dalam hardware dan software dapat menyebabkan perubahan sementara dalam program logic. Pengendalian input dapat membantu meyakini kesalahan input tetapi tidak dapat memproteksi perubahan dalam input data.
Tujuan dari pengendalian umum yaitu untuk mencegah orang yang tidak terotorisasi mengakses sistem dan untuk meyakini bahwa hanya transaksi yang terotorisasi dan data yang valid di input dalam terminal.
Metode Pengendalian Umum :
1. Pembatasan akses phisik ke terminal (hanya operator yang terotorisasi ).
2. Metode identifikasi terminal dan operator seperti password (hanya terminal dan user terotorisasi yang dapat akses pada sistem).
3. Proteksi data dari fragmentasi, intermixing dan encryption (mencegah unotorisasi tambahan atau charges selama transmisi data).
4. Perancangan skedul formal otorisasi bagi user.
2. Pengendalian Aplikasi
Adapun tujuan dari pengendalian aplikasi sebagai berikut :
1. Tujuan Preventive yaitu untuk meyakini transaksi yang di input adalah reliable, proper, otorisasi dan valid.
Pengendalian aplikasi pada input transaksi on-line harus ada prosedur tertulis yang memberikan pedoman bagi operator terminal dan assistant untuk mengurangi kemungkinan kesalahan. Prosedur tertulis seharusnya
mencakup operasi dari terminal misal prosedur aplikasi yang terkait untuk referensi dari file, input dari transaksi dan parameter data koreksi dari keying error, dan withdrawal dari transaksi untuk kesalahan sumber.
2. Tujuan Deteksi untuk meyakini bahwa data entry unreliable dan improper terdeteksi. Pengendalian aplikasi untuk mendeteksi kesalahan entry transaksi on-line termasuk dalam pengendalian batch dan test validasi.
3. Tujuan Koreksi untuk menyakini data entri unreliable dan improper telah dikoreksi. Pengendalian koreksi
kesalahan dari data entri harus langsung sebab masingmasing transaksi dikoreksi secara individual.
II. RISIKO KESALAHAN PROSES
Pemrosesan adalah fungsi dalam komputer yaitu operasi data (validasi data, kalkulasi , komparasi, penjumlahan, update file, maintenace file, sequencing, inquiry dan koreksi kesalahan) dengan instruksi program.
Risiko dari operasi pemrosesan sebagai berikut :
1. Kesalahan record yang dipakai dalam pemrosesan.
2. Kesalahan file yang digunakan dalam pemrosesan
3. Kesalahan operator memasukan data pada computer console
4. Kesalahan table value yang digunakan dalam pemrosesan
5. Kesalahan default value yang digunakan dalam pemrosesan
6. Kesalahan dalam pemrosesan akibat salah versi pada program.
7. Kesalahan dalam data input yang digunakan dalam pemrosesan tidak valid.
8. Data input tidak diotorisasi user saat pemrosesan
9. Kesalahan hasil akibat perhitungan yang tidak benar.
10. Kesalahan hasil akibat kesalahan logika pemrosesan.
11. Transaksi yang otomatis (dijalankan selama proses) tidak disertai kebijakan manajemen.
Risiko–risiko tersebut dapat dikurangi dengan menggunakan pengendalian umum dan pengendalian aplikasi.
1. Tujuan Preventive yaitu meyakini bahwa pemrosesan adalah reliable, proper dan terotorisasi.
Pengendalian umum dan pengendalian input berfungsi untuk mencegah kesalahan (data, program atau file) dalam pemrosesan sedangkan pengendalian pemrosesan digunakan untuk mendeteksi kesalahan. Pengendalian umum membuat lingkungan pemrosesan kondusif dan program aplikasi dan data (file) yang digunakan adalah benar.
Pengendalian input meyakinkan bahwa data yang digunakan dalam pemrosesan adalah reliable, proper dan terotorisasi. Untuk meyakini kebenaran logika program, proper dan lengkap dengan pengendalian umum yaitu :
1. Pengendalian pengembangan sistem menyakini bahwa program ditulis properly.
2. Praktek kepegawaian meyakini bahwa pengembangan sistem dan program dilakukan oleh personel yang kompenten.
3. Pengendalian library, pengendalian akses dan rotasi perkerjaan mengurangi peluang perubahan unotorisasi terhadap program aplikasi.
4. Pengendalian perubahan program dan pengendalian library meyakini bahwa hasil program adalah terotorisasi versi dari program. Prosedur recovery meyakini bahwa program untuk tujuan back up adalah versi terakhir .
Untuk mencegah penggunaan file yang tidak benar dengan pengendalian sebagai berikut yaitu:
a. Pengendalian library termasuk fungsi librarian untuk meyakini file yang proper untuk operasi, seperti pengendalian phisik atas penggunaan file, pelabelan file ekternal dan internal, proteksi file dari kerusakan phisik selama digunakan.
b. Pengendalian Prosedur operasi standar (SOP) dan dokumentasi operasi meyakini bahwa operator membaca label eksternal, cek console message dan lainnya serta mengurangi penggunaan file yang salah.
2. Tujuan deteksi adalah meyakini bahwa unrealible, improper dan unotorisasi proses terdeteksi.
Pengendalian umum yang kuat (pada pengembangan sistem dan dokumentasi) membantu meyakini bahwa program ditulis dengan benar. Pengujian menjadi penting pada sistem yang komplek dan adanya perubahan-
perubahan. Sistem yang komplek membuat kesulitan dalam mengantisipasi test posible logical alternative atau kombinasi alternatif sehingga menimbulkan konskwensi kesalahan dalam program tidak terprediksi selama pemrosesan. Sebagai contoh kesalahan dalam hardware dan software dapat menyebabkan perubahan sementara dalam program logic. Pengendalian input dapat membantu meyakini kesalahan input tetapi tidak dapat memproteksi perubahan dalam input data.
manajemen resiko
Manajemen telah banyak disebut sebagai “seni unruk merealisasikan pekerjaan melalui orang lain”. Definisi ini mengandung arti bahwa para manajemen mencapai tujuan organisasi melalui pengaturan orang lain untuk melaksanakan berbagai pekerjaan yang diperlukan, atau dengan kata lain tidak melakukan pekerjaan – pekerjaan itu sendiri.
Manajemen memang mempunyai pengertian lebih luas dari pada itu, tetapi definisi tersebut memberikan kenyataan kepada kita bahwa kita berutama mengelola sumber daya manusia, bukan material atau financial. We are managing human resources. Selain manajemen mencakup fungsi perencanaan (penetapan apa yang akan dilakukan), pengorganisasian (perancangan dan penugasan kelompok kerja), penyusun personalia (penarikan, seleksi, pengembangan pemberian kompensasi dan penilaian prestasi kerja), pengarahan (motivasai, kepemimpinan, integritas, dan pengelolaan konflik) dan pengawasan.
Pengertian manajemen begitu luas, sehingga dalam kenyataannya tidak ada definisi yang yang digunakan secara konsisten oleh semua orang. Seperti yang dikemukakan oleh Stoner ebagai berikut :
“Manajemen adalah proses perencanaan, pengorganisasian, pengarahan, dan pengawasan usaha-usaha para anggota organisasi dan penggunaan sumber daya organisasi lainnya agar mencapai tujuan organisasi yang telah ditetapkan.”
Dari devinisi diatas terlihat bahwa Stoner telah menggunakan kata proses bukan seni. Mengartikan manajemen sebagai seni mengandung arti bahwa hal itu adalah kemampuan dan keterampilan pribadi. Suatu proses adalah cara sistematis untuk melakukan pekerjaan. Manajemen didefinisikan sebagai proses karena semua manajer, tanpa memperdulikan keahlian atau keterampilan khusus mereka. Harus melaksanakan kegiatan-kegiatan tertentu yang saling berkaitan untuk mencapai tujuan yang mereka inginkan.
Proses tersebut terdiri dari kegiatan-kegiatan manajemen, yaitu perencanaan, pengorganisasian, pengarahan dan pengwasan.
Manajemen memang mempunyai pengertian lebih luas dari pada itu, tetapi definisi tersebut memberikan kenyataan kepada kita bahwa kita berutama mengelola sumber daya manusia, bukan material atau financial. We are managing human resources. Selain manajemen mencakup fungsi perencanaan (penetapan apa yang akan dilakukan), pengorganisasian (perancangan dan penugasan kelompok kerja), penyusun personalia (penarikan, seleksi, pengembangan pemberian kompensasi dan penilaian prestasi kerja), pengarahan (motivasai, kepemimpinan, integritas, dan pengelolaan konflik) dan pengawasan.
Pengertian manajemen begitu luas, sehingga dalam kenyataannya tidak ada definisi yang yang digunakan secara konsisten oleh semua orang. Seperti yang dikemukakan oleh Stoner ebagai berikut :
“Manajemen adalah proses perencanaan, pengorganisasian, pengarahan, dan pengawasan usaha-usaha para anggota organisasi dan penggunaan sumber daya organisasi lainnya agar mencapai tujuan organisasi yang telah ditetapkan.”
Dari devinisi diatas terlihat bahwa Stoner telah menggunakan kata proses bukan seni. Mengartikan manajemen sebagai seni mengandung arti bahwa hal itu adalah kemampuan dan keterampilan pribadi. Suatu proses adalah cara sistematis untuk melakukan pekerjaan. Manajemen didefinisikan sebagai proses karena semua manajer, tanpa memperdulikan keahlian atau keterampilan khusus mereka. Harus melaksanakan kegiatan-kegiatan tertentu yang saling berkaitan untuk mencapai tujuan yang mereka inginkan.
Proses tersebut terdiri dari kegiatan-kegiatan manajemen, yaitu perencanaan, pengorganisasian, pengarahan dan pengwasan.
Selasa, 17 November 2009
Nedved Kembali ke Juventus?
Salah satu pemain terbaik Republik Ceska yang melanglangbuana di percaturan kompetisi
Eropa, Pavel Nedved, dikabarkan segera kembali bergabung bersama Juventus, klub yang diperkuatnya selama delapan musim, 2001-2009. Di musim panas lalu, tepatnya 11 Juli 2009, Nedved memutuskan meninggalkan lapangan hijau (Baca: Nedved Sepenuhnya Gantung Sepatu).
Kembalinya Nedved ke Turin terang saja menimbulkan pertanyaan. Akankah peraih Ballon d’Or 2003 itu bakal kembali bermain? Tentu saja tidak. Yang pasti, ada dua opsi terkait pekerjaan baru Nedved bersama Bianconeri, yaitu sebagai pelatih tim yunior atau masuk dalam jajaran dewan direksi.
Menurut Tuttosport dan dikutip Football Italia, di awal musim, allenatore Juve, Ciro Ferrara sempat menyodorkan tawaran bagi Nedved untuk bergabung dalam staf kepelatihan tim. Nedved menolak. Kini, benak Nedved diklaim telah berubah.
Dengan dukungan dari Presiden Klub, Jean-Claude Blanc dan Direktur Sport, Alessio Secco, Nedved disebut-sebut telah setuju untuk menjadi salah satu direktur klub. Dengan masih terbukanya kemungkinan bergabung dengan tim yunior La Vecchia Signora, di mata Ferrara, eksistensi Nedved diperlukan sebagai jembatan penghubung antara pemain dan jajaran direksi.(MEG)
Langganan:
Postingan (Atom)