 |
|
|
|
Hello,
When modeling a business system (solution agnostic) there are a number of (primary) business activities that take place along the value chain and in the supporting areas e.g. Place Purchase Order, Receive Goods.
These primary activities are implicit in the context diagram (by way of data flow), explicit at a the level one DFD / high-level Business Process / Use Case Diagram (depending upon preferred notation) view and are then further detailed by individual process flow diagrams and/or Business Use cases (again, depending upon preferred notation) to illustrate the tasks and what happens.
However there are also monitoring and controlling (secondary) activities that take place e.g. Monitor Stock Levels, Monitor Sales, to aide these primary activities.
These secondary activities have some distinct characteristics:
· They are ‘one activity’ processes
· They take place independently of other processes
· They occur on an adhoc basis i.e. without a specific business event or set timing trigger
· Their input is data (raw) and output is information (organized) - to enable decision making
· There are often a significant number of them
Thus, in implementation primary activities usually become data entry screens and secondary activities result in dashboards/reports.
Specifying the requirements (text) is straightforward (functional versus informational), however (IMO) secondary activities are less suitable for modelling pictorially and I am interested in how you represent them in your models.
Context diagrams are straightforward as data-flow is implicitly evident, but at the high-level (activity explicit) view and subsequent detailed views (task explicit) how do you model these activities?
- High-Level View
- Do you treat them the same as any other activity and include them all individually in the High-Level View (which may crowd the picture)?
- Do you bulk them together into a single generic bucket (which I personally dislike as it's non-specific)?
- Or perhaps you don't illustrate them in your High-Level diagrams at all and only model the 'primary' activities (which is not user friendly for the business to review)
- Detailed View
- Do you create a process flow/Use Case narrative for the ‘one-step’ activity?
Cheers,
Joe
|
|
|
|
 | |
|
|
|
Hi:
Processes/activities that occur independent of other processes? In data flow diagramming no such exist. You yourself say that their input is data: the data has to come from somewhere.
To handle complexity (such as a large number of lower level ad hoc processes), I use decomposition. Sometimes, I decompose down five levels or more to handle all the details.
But, especially if your system is complex, the only way decomposition is going to work is if you employ a logical, natural partitioning. And the only way to obtain such a partitioning is if the modeling methodology actually guides you through such. Data flow diagrams guide you through partitioning; use cases do not.
Tony
|
|
|
|
| |
|
|
|
For the modeling aspect, BPMN is a pretty good modern replacement for data flow diagrams. All of the heirarchical decomposition, allows for local data, includes actual message, mixes roles (lanes) and disjoint systems (pools) into the diagram. Clean diagraming (particularly in V2.0) that can be as simple or expressive as you like. I find that the extra expressive power is helpful in drilling down use cases where multiple use cases are going to involve same or similar tasks, or cross system boundaries. There is a notion of 'ad-hoc' processes where there is no sequence among the included tasks -- data dependencies and general context is captures without need to have control flow in and out. There is nothing wrong with a 'one task' process. It is triggered, does it's thing and ends. At some level of aggregation, every process is represented by one box.
The larger question of how to handle subsidiary processes is a great one. And one that is generally ignored or actively surpressed -- to the detriment of project success. One key difference between the 'direct' processes and 'support' processes is that the direct processes tend to have a very clear objective with regular progress between beginning and end. Think order-to-cash. Each instance is a new object. Support processes tend to loop on the same object, say the inventory. These are, in fact perfectly fine usecases or processes, but are triggered by internal or non-revenue external events. The inventory monitoring use case might be 'daily, check level; report level -- Alt: reorder'. Instead of a daily or ad-hoc trigger it can be more sophisticated, say an event thrown from the order processing 'commit inventory' task when the available inventory passes a threshold.
Perhaps the most important point here is that processes interact with each other and that ignoring that interaction is malpractice. The other side of the interaction may well be out of scope, but it is still necessary to understand and document the dependency. Ideally, negotiate effective integration.
|
|
|
|
| |
|
|
|
With BPMN, sequence, flow of control, flow of data, and other stuff is all shown on the same diagram. The result is, especially for complex systems, diagrams that get soon get so complex that it so becomes impossible for the analyst to uncover where his/her mistakes are. Or (probably more typical) the BPMN analyst just forgets about the data flows: very problemic as a process is defined by its inputs and outputs and, more importantly, only by following the data flows can we properly partition the system - prerequiste to effective decomposition, which is necessary for modeling all the details that the questioner mentions.
With data flow diagrams, at higher levels, we only show flow of data. At low levels, we show flow of control/sequence. Result: diagrams that are easly readable by the analyst AND that are much easier to walk through with the end users.
I say that focusing on what the most modern is not the way to go. But...... if one wants to do such, then consider the BABOK 2.0. And it is a functional spec on how to create a functional spec. And it is the latest thing! So what modeling process techniques does the BABOK 2.0 use to organize the processes that a BA performs? Answer: input/process/output diagrams. Data flow diagrams are integrated input/process/output diagrams. Therefore, according to the "use what is most modern" school of thought, data flow diagrams are the latest and greatest and BPMN is old.
Tony |
|
|
|
| |
|
|
|
Thanks for your response ajmarkos. Although, I may not have communicated my question clearly, as I am comfortable with my chosen mish-mash of notations. Here’s how I decompose:
- Context Diagram – showing system boundary (Level Zero – Data Flow)
- High-Level – Explicitly showing activities / processes (Level 1- Data Flow)
- Process Diagram – show activities, dependencies and decisions etc. (BPMN)
- Narrative – describing tasks/steps to be taken
My analysis forces a fairly flat structure to avoid the never ending decomposition story, and find it great for primary activities, but my question focused more on how to model secondary activities i.e. the seemingly standalone actions (that feature at level 1 with no lower level to decompose to). I agree that these are easily handled by dataflow, however my dislike with this approach is that if one has (let’s say) ten activities this just crowds the Level One view with half the diagram having processes that interact with one another (great), and the other half has processes that simply input, feed from a datastore, output (not so great).
ncaswell, your example is spot on, and I agree they are perfectly good use cases based on a timing trigger (daily, weekly, just because it’s time etc). The functional requirements will certainly include and define them as such, but I was considering how the many support functions represented pictorially at the Business Requirements Stage?
Over the weekend I was thinking about this question and realized they are effectively a means to access information for the user and thus are “reporting” requirements and so I will not clutter the diagrams with them. Reporting and administrative activities will all require functional requirements, but for now I will avoid explicitly showing them as activities/processes (and rather list them as informational requirements) and/or include them as input/prerequisites for the processes the information is needed i.e. ‘stock level report’ before ‘ordering’.
Many Thanks for your responses.
Joe
P.S. I agree ajmarkos. DFDs rock – maybe because I was brought up on them – but they have always served me well for initial analysis, understanding and partitioning.
|
|
|
|
| |