Note: This Is a Template, from a Business Analysis, Describing a Business Process, Including

romanization

[Note: This is a template, from a business analysis, describing a business process, including input, output and intermediate products from a logical perspective.
The template should not be read as a tight pattern. It is thought that the chapter / sections not prescriptive classification should be seen. It is also not true that all issues should be addressed per se in the description. It is for the author to include one good choice.
The template can in principle both to describe the IST and SOLL used. For the IST, certain sections of this template does not apply. Take it away.
Besides describing the business process (and products) can / should be from a business analysis to other aspects of attention, thinking COPAFIJTH. This template is not intended for this.
The template shows at certain points also describe how certain things can, for example in a tabular form. This should be seen as an example. Again, the freedom given to the author to the document text in a certain way.
At certain points are also included standard text parts (in green italics). Again it to guide the author to be seen.
This template is "bottom-up through different existing business analysis documents (both CBS) examine and draw the topics to include.
If you template you should certainly not feel obliged to all chapters and sections to fill, remove it from. Keep it as short and simple as possible: "Fit to purpose".]
Versioning
Version history
Version Date Description Author
Active distribution per version
Distribution version
Index
1. Introduction 4
1.1 Target 4
Reason 1.2, 4 background and purpose
1.3 Definitions and abbreviations 4
1.4 References 4
1.5 Principles 4
2. Definition and context 5
2.1 Place in CBS-wide architecture 5
2.2 Background 5
3. Characteristics of statistics / research 5
4. Requirements Process 5
5. 5 Information Model
Business Objects 5.1 Model 5
5.2 Data sets, rest areas and interfaces 5
6. Process Model on axis 5
7. Process Model detail 5
Section 7.1 Process May 1
7.1.1 Activity 5 a
7.1.2 Activity 5 b
Section 7.2 Process May 2
8. Methodology 5
September. Difference between old and new trial 5
A. Appendix: Accountability versus architectural principles 5
Appendix B: Guidelines Used 5
B.1 difference logical and operational 5
B.2 principles in the logical model 5
B.3 Design and implementation 5
<title>
1. Introduction
1.1 Audience
This document is intended primarily for members of the project (part) <projectnaam> project dealing with the (re) design the process involved and <name afdeling> employees to be engaged in <name proces>. In addition, the target business architects. They must be based on this document are in a position to review the architecture frameworks do.
Reason 1.2, background and purpose
<Describe briefly what the reason is that this document is written and what is the purpose of this document. Following is an example of a redesign statistics / research. The aim is eg to create a common image to be between project and business. Describe also any background / history that the reader needs to bring the document to interpret.>
1.3 Definitions and abbreviations
<some Reference to a single course can Glossary/Begrippenlijstdocument ook.>
Definition
1.4 References
<Neem Only documents which actually referenced from this document.>
Document Version Date Author
1.5 Principles
<Beschrijf What uitgangspunten/aannames had to make this document.>
2. Definition and context
<Describe where to consider (partial) process fits into the architecture domains. Describe also d.m.v. a context model with associated description which actors interact with the process. Give a clear description of the boundaries of the process.>
2.1 Place in CBS-wide architecture
<Create Defining example by using data plaatjes.>
Figure 1: Value Chain Plate CBS architecture
In the CBS-wide business architecture in the production the following business areas identified:
Observing
o Preparing and sending
o survey, unify and control
Processing
o Connect, derive and create cool
o aggregate, assess and integrate
Publishing
o Protect and create publishable
o Providing
The process described in this document includes the domains <domeinen>.
<The scope of the picture can be indicated by a cross through the fields to put outside the scope.
The picture is an example, the implementation domain (production). But if the design is a considered process, you naturally create a different picture.>
2.2 Context
<Describe the context in which it becomes clear what the scope of the process and to consider which actors are. An actor is a role / department / process / body interacts with the process.
Make taking a context model / diagram. As necessary: Describe each actor and describe the interaction (say, the arrow between process and actor).
Actors are stakeholders. However, there are stakeholders who are not actors. These stakeholders are not considered relevant to the business, but to manage the project. Consider what you doing this. The story is perhaps useful here to describe all stakeholders, but this is also an option in another document to describe (eg a project document or a separate stakeholder analysis document).
Describe the context in other processes, so that the relationship between the described process and other processes becomes clear. Also another process can be regarded as an actor.
Above is one example of a context diagram. Use of symbols may also. And below is another example.
Give a brief explanation of the actors and the inputs and outputs of the process.
Actors
Actor Remarks
<bv "DANS">
<bv "Proces DRT">
Input of process
Input Frequency Remarks
<bv "Enquêtedata"> <the frequency input komt>
Output of Process
Output Frequency Report Period Remarks
<Eg "Tables") <the frequency output supplied wordt; eg 1x per month.> <the period covered by the example of outputs heeft; Jaar>
3. Characteristics of statistics / research
<Describe some characteristics of the research / statistics. You can also comment on the existence of statistics / research.>
Client <opdrachtgever the external name onderzoek: CBS, partij>
Report Period Type <Type period for which published wordt: maand, kwartaal, jaar, ….>
Frequency <frequency which is published. Eg: an investigation, a period of one year and 1 in two years take place>
Reporting Unit <statistical unit which as a result of the investigation reported. Eg, business entity, individual, household, ...>
Observing Period Type <Type period in which the sampling unit vindt: maand, kwartaal, jaar, …>
Target population living in the Netherlands <bv 0 years and ouder, persons belonging to private households and who are enrolled in GBA.>
Sample Unit <bv Persoon, adres, bedrijfseenheid, …>
Draw sample <Bv: tweetraps> 1x per month.
Sample size <Create possibly distinguish between the solid and the number of units deployed eenheden>
<Eisen Response to the response or expected respons>
Modes <Applied modes. Eg: CATI, CAWI>
<Refer to the observational design example for a detailed description of observation.
It is also possible that the input multiple output needs. The first grid next to each output you'd need a separate diagram is recording.>
4. Requirements Process
<In general, of course, if you create something new, namely a new / updated business, you first have the requirements, needs, current problems and constraints have to clear. If this is not clear, it is essentially impossible for a desired SOLL situation to describe.
Describe the bottlenecks in the current situation. What is the problem, what is the cause?
Describe what requirements there are for the process that the solution must satisfy. Requirements may be of different stakeholders: the business itself, the process of customers and others These are requirements that must be taken in forming the logical process model.
To clear the requirements to get you something of a stakeholder analysis should do and should look to the business objectives. But this document does not show the entire stakeholder analysis record. Also "methodology" which is a stakeholder requirements and provides frameworks. Look also at the instance method series.
Check out the current situation which demands, whether by implication, handled?
Describe the requirements concise, but SMART (specific, measurable, acceptable, realistic and time bound).
Business rules also impose requirements on the process. There are several types of business rules. Describe here only the business rules which impose conditions on the process. Describe any business rules that describe how an activity should be performed. This belongs in the draft on specific products (requirements, etc.).
Examples (fictitious):
- A statistical table must be protected
- Before a statistical table is protected, it must be endorsed by the process manager.
- A data set should be checked for plausibility before a coupling surface can be stored.
- The enrichment of the observed data with GBA-data should be made before these dates serving non-response analysis is provided.
- Only one account can make contact with a top-20 business unit.
Note: The chapter is included here primarily to make you aware of the requirements that must be explicitly made. Perhaps it is better / easier to determine the requirements and business rules in a separate document to be included. This has the advantage that it can separate checkout process. And maybe we will get in the future to allow for an appropriate template.
5. Information Model
5.1 Business object model
<A model of business objects can be very useful to the reader in terms of conceptualization. It is basically a form / expansion of the glossary. It is a structured description of objects and the relationships between objects. A business object model is device independent.
Create a logical model, go here no physical model.
IT development also needs a business object model. For IT development is a comprehensive model is needed, this is often a separate document is created. In the underlying document can suffice with a simple model. What simple, it is an estimate of the analyst while recognizing the needs / knowledge of the intended readers.
Often it is good to input, output and process to be considered separately. Therefore create a separate object model of the input, a separate model of the objects in the process itself and a separate model of the objects in the output.
If you want a detailed description of the logical information collections and positioned a coupling surface, please use the template "Logical Information Model (LIM), see Analysis undergraduate architecture / byproduct / Template Logic Information Model document.dot.
Sample business object model:
5.2 Data sets, rest areas and interfaces
<A dataset (micro database, table) can be a haven. And one has a resting place in a coupling surface. Describe a data set whether or not a pause (with the explanation thereto) and in which the base pair plane belongs. Interfaces are: pre-base input, input base, micro base, stat base, output base and post output base.
The data sets can be used as inputs or outputs have included in the model context, this section should in principle be mentioned again.>
Pause Population Dataset Object Type Torque Right Statement
<bv Waarneemproduct> <Yes> <Bedrijfseenheden in Nederland> <Bedrijfseenheid> <Inputbase>
Ready <bv onderzoeksbestand> <Yes> <Microbase>
<bv Research File instance that is linked to income data but needs further enriched worden> <Nee> <nvt> <is between a file that serves no other than input for a next procesactiviteit>
<In the process model, these data sets to gain a spot as input, output or intermediate product of a (sub) process.
It is certainly not the intention of each dataset in detail in terms of variables, etc. to describe. As you can template "Logical Information Model (LIM)" for use, see Analysis under architecture / byproduct / Template Logical Information Model document.dot.
6. Process Model on main line
<Describe the process axis. Identify at this level the sub-processes (or subprocesses), the consistency between them and the input and output of the process.
Depending on the scope of the process you may be considered useful in the multi-level hierarchy of sub-processes to appoint.
The process you can be considered an implementation process or a design or management process or a mixture thereof. These are three types of processes (domains) in the architecture distinguished from each other. In any case you care for each (sub) process and makes clear activity or performance, design or direction is.
If you describe an implementation process should, in principle, directing its attention to be paid. Both are closely intertwined.
Enter the main level also interfaces with other processes again. This should in principle processes are also in the context model mentioned.
Also describe some characteristics of the process as a whole, for example:
Trigger <trigger the Describe / the event that starts the process. Eg the entry of the input or to achieve a given day (eg, the first of each month.>
Frequency <How often is the process (average)? eg: 1x per month>
Turnaround <How long is the process from beginning to end (gemiddeld)?>
Below is an example of a process model which is considered a main process.
And this is another example:
You see in the examples that the rest areas are appointed.>
7. Process Model detail
7.1 Process Part 1
<Describe the process part. Identify the activities at this level (or process steps), the consistency between them and the input and output of the subprocess.
Identify the appropriate stakeholders. This process will be outside the area, so suppliers and customers, or in the process, so those activities. Call it in the latter than as roles, departments and certainly not as names of employees. Swimlanes modeling activities will be an option.>
7.1.1 Activity A
<Describe the activity and name while the input and output of the activity. Identify also the design products needed in the activity, eg, torque requirement, weighing model.
The level of operation is not normally described in a logical process model, this is only an operational model discussed.>
7.1.2 Activity b
7.2 Process Part 2
8. Methodology
<Describe the main statistical methodology used in the process. Keep it short. The detailed elaboration of the methodology belongs in another document at home. Refer it to do.>
September. Difference between old and new process
<To describe the differences support the process analysis and supports the writing of the transition plan (how do I get from old to new).
To describe the differences may also be in a separate document. The latter has an advantage if the process described at one point and therefore deployed the new IST situation has become. This document is a description of the IST, a description of the difference is probably not really in place in this document.>
A. Appendix: Accountability versus architectural principles
<The business architects should o.b.v. This document can test whether the (BI) architecture frameworks are met. So take this Annex BI principles and describe each principle whether there is compliance or not. If not a business architecture principle is satisfied, why not substantiated.
This is basically only useful if there is a new document (SOLL) situation is described. If only the IST is described in the assessment frameworks irrelevant. Let this Annex away.>
Appendix B: Used directives
<Deze Annex is intended as an explanation for the reader of some business analysis used by the general richtlijnen.>
B.1 difference logical and operational
The difference is explained by an example.
Logically, you can argue that an activity where you make something a little different than an activity where you get an error corrected. Logically would you three distinct activities: monitoring, control (adjust) action and correct the error (if possible action). In doing so you can separate the responsibilities: those that control does is anyone other than those the correction.
In operational terms, making this distinction might not be desirable or necessary or unnecessarily complex. The operational model can then be appointed as an activity performed by an employee at a time.
In the conceptual model is therefore not yet discussed tasks, powers and responsibilities. There is a process activity has not indicated who (which role or organizational unit) or carry out the activity is responsible for.
Another example is the conceptual difference between a torque requirement and an enrichment requirement. The torque requirement describes eg how cases are linked to the GBA. The enrichment method describes the variables in the GBA with the enrichment should take place. From an operational perspective, it is probably not desirable to make this distinction and this is seen as a requirement.
Also, a logical model has not yet appointed a extent activity manually. The operational model does. It also means that the logical model has not spoken on IT systems.
B.2 principles in the logical model
The following principles are applied in the logical model:
1. one step process in which data and metadata are modified split, a process step modified either metadata or data
2. one step process in which a statistical analysis and a statistical non-split operation occurs, a process step is either a statistical or a non-statistical treatment
3. one step process in which a control and a split operation occurs, a process step is either a step or a control processing step (a nav com operation follows the control).
4. one step process where the quality of the dataset is improved by a split step process whereby the meaning of the data set is changed.
5. directed activity (such as determining a bijstuuractie) is a different process than a step in implementation and design activity
6. a design activity (such as modifying control rules) is another process step than an executive or management activity.
B.3 Design and implementation
The architecture distinguishes between design and implementation. Designs include topics such as identify / describe all kinds of rules (like rules of inference, torque requirements, cool make rules, etc.) and defining / describing the products (data sets) in terms of metadata (such as name and meaning of variables, population delineation, etc).
The implementation of the production process.
Between the design and implementation is still the 'building process', the process by which the design is realized / operationalized.
The process described here involves only the process of implementation. The premise is that when implementing any design (design products) are available ..
Ideally, all designs must be completed before production (implementation) is started. In practice, it might not. For example it may be that the process initially to a particular activity can be completed, but that first a design activity to be done before further activities in the production are exported. It could also mean problems found in production lead to adjustment of design. For the employee who is doing, then it seems that designing and implementing more or less simultaneously merge with and done. In this document, this is logically separated, it is not about running on the design.
[Note: if the process does not describe implementation process is sample text above, of course not applicable].