I have a question. suppose we wanna a BPMN diagram for transferring soccer player from team A in country A to team B in country B and to do that the federation of A should cancel the player registeration for team A and federation B should accept registeration for team B.
my question is that if we should have two swimlane with role federation A and B or one swimlane is enough? or also we have to had two pools ?
Please help me for this question. thanks a lot
The correct approach depends a lot on what you are modelling and why. I will give you an example of motivation for each of the mentioned methods so that you could get the idea and make the right choice yourself.
You don't really care about who does what in your scenario and the main point is the order of actions and exceptions. No swimlanes are needed, just put your diagram out there:
Your scenario is whole and should never be decomposed into parts (e. g. Cancellation and Registration) because there is very little or none at all sense in looking at the parts on their own. Make one pool with two or three (possibly for the player himself) swimlanes:
Your scenario can be decomposed and it makes good sense. The process occasionally stops at a point of Cancellation (without new Registration).
Use different pools with separate process flows:
Also, use a separate Blackbox Pool if you don't know what a participant (a player or a federation) actually does and you can only communicate with it by some kind of messaging (e. g. -Accept? -OK).
Related
I've got a problem with how to transform Petri Diagram to BPMN. I don't know how to "simulate" tokens, and the situation when the flow goes back to the start.
Can anyone show me how the correct BPMN should look? :)
I basically see the three BPNM tasks Record proposal, Grant a loan, and Refuse and notify here. The Consideration place is actually a choice and would become a BPNM gateway.
You example seems to involve two actors: one making proposals and another one deciding whether to accept or refuse a proposal. This should be modeled by showing a separate pool for each actor.
If there are multiple instances that make the proposals, the multi instances attribute can be used on the pool.
If it is important that you can process exactly three proposals, I would include this in the far right condition (gateway) or as a text annotation.
So my idea of a BPMN diagram is this:
But it really depends on what aspects of the process you want to show in the model.
I'd like to ask you a question about Collaboration diagrams.
Unfortunately I cant find anywhere answer to my question. During our classes I was shown collaboration process, that used connection between various activities, gates etc. But on those there wasn't any pool displayed. It's only showed with logical diagram of an activity (Start Event-> Dress up->Is it raining?)
But when I was studying from various online websites they had always 2 or more pools. One pool for each Business process.
My question is.
Is it possible to have a communication diagram without any pool (or even 1 pool)?
Technically, a collaboration diagram usually contains two or more Pools (BPMN 2.0 specification page 110/140 in PDF), but a Process that represents the work performed from the point of view of the modeler or the modeler's organization can be considered “internal” and is NOT REQUIRED to be surrounded by the boundary of the Pool (page 112/142 in PDF). This means having only one pool in a collaboration diagram is possible. However, one wouldn't consider a process diagram with only one pool and no inter-pool communication (or no pool at all) a collaboration diagram, but rather a process diagram.
On a more practical note, most BPM(N) vendors and practitioners don't distinguish between collaboration and process diagrams and refer to BPMN diagrams generally as process diagrams. Also, it's very common (but not necessarily good practice) to not model any pool to keep things simple.
Intro
The company I work in (it is an intern-like position though, until I am done with university) recently implemented an automated warehouse solution, where goods are transported by means of autonomous shuttles. The basic functions of the shuttles are controlled by onboard electronics (microcontroller), routing through the warehouse racking is done by software solution which in turn communicates with our ERP solution. Effectively the ERP solution handles the whole warehousing.
Task
There are well documented processes for every of the four layers (operator who loads the the shuttles, shuttle itself, routing, ERP) individually. But since we kind of puzzled all four of them together to one solution (which was kind of new to all of the participating companies), there are only vague, on-the-flyish process descriptions involving all four layers available.
Now I have been tasked to come up with a solution to illustrate the processes at work.
Example
ERP signals goods in demand at assembly station A1
Warehouse operator looks at screen and starts loading boxes to be picked up by
shuttle
Warehouse operator puts in details into ERP, such as count/weight, box number,
...
Warehouse operator clears boxes for pick-up (by confirming inputs in ERP)
ERP generates transport order
ERP sends transport order to routing software
Routing software sends telegram to shuttle control
Shuttle control turns wheels and asks for directions to pick up boxes
...
Question
As mentioned, I have to graphically represent the kind of processes similar to the one shown in the (easy and not complete) example above. I need to incorporate the operator's actions as well as basic communication between shuttle, routing software and ERP.
Since I attended a course on BPMN at university it came to mind immediately. But now, after immersing myself into information about BPMN for several hours I still can't conclusively tell if BPMN helps my efforts or just further complicates the whole thing.
Is BPMN the right tool for my purpose?
Disclaimer
I am not a Business Analyst. I have looked at alternatives to BPMN (simple flowcharts, activity diagrams, ...) but they don't seem to fit.
Just putting together the existing processes for every respective layer yields no result, owing to the different and sometimes too detailed process descriptions.
Edit
The ERP is SAP ERP 6.0 EHP7 with integrated WMS component.
TL;DR: use the notation you would be implement process in, i.e. choose BPMS, not BPMN.
The notation itself means nothing unless it has proper tool for modelling and further process implementation aka BPMS. You can find dozens of comparisons (e.g. BPMN vs EPC or BPMN vs BPEL), however they won't help you unless you have clear understanding where and how you will be implement you modeled process.
Generally speaking, EPC is used for more high-level view of the process, whereas BPMN is utilized for more fine-grained view, where all technical details of communications between peers can be described. However, it depends.
I also recommend you to review this table
and answer the question to yourself whether your process changes (in)frequently or not, and whether you need separate BPM tool.
How I see it from your description: you have four participants (four layers), which are four lanes in BPMN terms, and they are collaborating/communicating with each other during the process. Generally speaking, this fits to BPMN application area, but personally I feel that you should stick your ERP tooling. I don't know which ERP you use, but every serious ERP solution includes tool for process customization. For example, SAP has Workflow,
which can widely enhance and extend existing processes within SAP. Probably, your ERP have it too.
Again, it's not clear which warehouse management system you use and if it is integrated to your ERP. It seems to be not, and it seems to be some old legacy system, because of which you start re-modelling the stuff. In this particular case it might me wiser to acquire special advanced warehouse management package (take a look at SAP's EWM features as an example) which can cover most of your requirements.
We have a number of processes that rely on interactions between two people/groups. I am trying to figure out the best way to illustrate this in BPMN.
CONSIDER:
Using the example of a pizza order, I call a pizzeria to order, an order-taker answers the phone and then we discuss my order. I am trying to accurately capture the "we discuss the order" portion of the process. Here is how I envision the diagram playing out. I call, they answer, then there's branching for a simultaneous exchange, which converges at the end of the call and my order is finished. Is this illustrated correctly? or are there better ways to show that two different entities communicating with each other at the same time to accomplish a task?
The moment you want to show interaction in greater detail than high level bird view, you typically run into troubles when remaining within the paradigm of using "one pool with several lanes". In such a case you need to draw a so called "collaboration diagram", which means you make use of several pools and hence several process definitions interacting with each other by means of message exchange. I give you an example here:
You may use those envelope symbols attached to the message flows, but you don't need to.
The big advantage of that approach is that you can now show that those processes are dependent on each other, yes, but each participant also wants to remain in drivers seat of his/her own process, e.g. by deciding what to do if the other side doesn't provide the desired answer, doesn't do anything within a reasonable time and so on. Furthermore you can look at that diagram from both perspectives and people will actually see "their own process" - and not something mixed with the concerns of others involved.
For that same reason BPMN also offers the concept of "collapsed pools" to be able to look just at the communication from one side and treat the internal details of the other side as a kind of "black box":
Are use cases just multiple user stories??
What are the benefits of using user stories over use cases.. and vice-versa... When to use one over other...
Does all agile methodologies uses user stories??
Actually, the original use cases (see Jacobson's OOSE) were pretty lightweight, much as user stories are now. Over time, they evolved until a common format for "use cases" now is a complicated document with inputs, outputs, inheritance, uses relationships, pseudocode, etc. Programmers, in general, try to convert everything into programming.
In any case, the attempt to defined what distinguishes a "use case" from a "user story" fro a "scenario" is pretty futile, as it's hard to find two authorities who agree.\
Personally, I find the pattern "[Actor] [verbs] [noun] to get [business value]" helpful. If it gets over about a paragraph of text, it may be too big.
When it comes down to it "agile" is just a label, and people disagree over exactly what it means. Similarly people call very different things "use cases."
In my experience the primary difference between the two is that a user story is focused on the user, and is usually shorter and less formal - ideally, it should easily fit on a postcard. It probably doesn't give details of error handling etc.
Use cases can be much more formal (although some people write them informally too) - they focus on every interaction with the system, and may well go into more detail about several different systems/actors/etc within the same use case.
That's just my experience though - chances are everyone will have used these tools in different ways. I wouldn't get too hung up about labels - just use what works for your project.
Use cases aren't compilations of user stories.
User stories are generally much simpler than use cases. I think use cases try to cover absolutely everything to do with the behaviour of some aspect of the system. That is, all behaviours, all error paths and all exception handling.
The recommended template for a user is:
As a (role) I want (something) so that (benefit)
(Thanks Mike Cohn for providing this simple template)
Descriptions of behaviour expressed like this are more agile.
This sort of template lets you describe behaviour using different levels of detail. For example:
for those stories being implemented in a much later sprint, you can describe behaviour in a high level sort of way, e.g. as an ops team member I want to monitor the system remotely so that I can determine system health while on the road.
for those stories being implemented in the next sprint, you can describe behaviour is a slightly more detailed way, e.g. as an ops team member I want to have a dedicated ops only login so that I can check system health.
for those stories being implemented in the current sprint, you can describe behaviour in a highly detailed way, e.g. as an ops team member I want to have a web interface so that I can check current status of the ingest ftp server.
IMHO Use cases are much more carved in stone! And hence can be a problem to update after the initial version.
HTH
cheers,
Rob
In one word, no.
Use Cases are typically detailed specifications laying out how some particular piece of functionality is going to work, or how a specific user is going to utilize the system. It typically is in the voice of a specific user (or Actor) and is fairly self-contained.
A user story on the other hand is "an invitation for discussion". It is typically one or two sentences. Here is one good resource for that. And Mike Cohn's User Stories Applied is well worth it.
The typical syntax is "As a <user> I need <functionality> to achieve <business value>", or "To achieve <business value> as a <user> I need <functionality>" which drives home the value of the story.
User stories are not meant to be stand-alone, but meant to invite discussion of the story between the developer and the customer (or customer proxy).
You can think of a usecase as a user story, but not the other way around. A usecase will cover multiple "endings" to the story, special requirements (e.g. form fields must be entered in format xyz, and show error message 123 if the user enters a field in the wrong format). Also, a usecase can include additional references to external documents, such as security guidelines.
User Stories is a tool used in Agile development to make sure you create the product your user really needs.
It describes rather why you should make this or that feature instead of HOW or WHAT feature.
From my personal experience, it's a great way to balance the client's and developer's vision to create a better product.
Unlike US aUse Case focuses on WHO uses your product. Here is the difference.
I'd say there is no other such instrument for an Agile developer as User Stories. If you want to learn how to write them successfully, check out this post.