Main Area and Open Discussion > General Software Discussion

Software for Business Process Modeling?

<< < (5/10) > >>

steeladept:
I found the best way is by living through them.   :-\

Sorry it isn't easier than that.  That said, I do have an MBA (which may also prove useful to you).  The best bit of advise I can say about this is to look at the process at hand.  See what works well and what doesn't work so well.  Then, this is key, ask the people implementing the process what works well and not so well.  You may be surprised to find they are very different things.  Learn how they would improve the process, learn what the caveat's are, and listen to them.  Where I work, they did all but the last, then said everything is good as far as they could tell.  Then they spent something like $40 million for Accenture to come in and tell them the same things many employees were saying but fell upon deaf ears.

Lastly, when it comes time to impliment any changes, to get the best buy-in you want to think about the job from the lowest to the highest position.  Start at the lowest position and use those employee's ideas where possible.  They know best what is going on in their area.  Also, keep them in the loop on your own process and how it is coming. One downfall I constantly see is a suggestion is taken and it goes into a black hole.  People want closure - if you ask for their thoughts, let them know if it was accepted, implemented, replaced, whatever.  Give feedback to the line worker on where the project is - if you want to utilize their ideas and they know this but they also know it won't get implimented until the project kicks off 3 years from now, at least they know why it is taking so long to impliment.  This isn't platitudes, this is (un)common courtesy and it makes acceptance MUCH easier.

BPM and more importantly Process Improvement is a huge job that is nearly impossible to accomplish single-handedly.  It takes total buy-in from the top and a LOT of time and effort for each process (of which most companies, even small ones, have 100's if not 1000's).  Moreover, if done correctly, it is a process itself - a continuous process if you will, not a project that has a definite start and end time.  The "project" is to get the buy-in and to kick it off.  Once that is done, the project is done, but the process MUST be continued to be useful.

superboyac:
Thanks steel.  These are issues I'm already running into.  We have asked people to look at certain processes that they are experts and give us comments about how it is documented.  The comments I received were all spellchecking, grammer, etc. type of comments.  i was like, no, I'm not asking you to proof read these documents.  I need you to tell me if this is the way things are done, and if not, what is the current procedure.  So, yes, i realized yesterday that this is going to involve a lot of collaboration and discussion.

steveorg:
I found the best way is by living through them.   :-\-steeladept (June 16, 2010, 10:11 AM)
--- End quote ---
Truer words were never spoken! Actually, I concur with everything that steel said. It doesn't always take an MBA. You may learn the craft best with a focused academic background like IainB's but you can still do a credible job picking it up on the street like I did.

Take an inventory of the skills that you bring to the table. Your passion for software gives you a huge leg up. It indicates that you likely have the logical kind of mind that is essential to the task and you probably will have insights into software usage that are not apparent to the typical user, even people who are otherwise skilled in using a particular package. The ability to straddle the IT and operational sides is incredibly useful.

For a more formal view of documentation and controls, you may want to search for materials on ISO 9001, the COSO Framework (developed for financial operations and commonly used for Sarbanes-Oxley but more broadly applicable to other operations) and COBIT (IT operations). For examples, you may be able to find samples of PCI-DSS (credit card processing controls) and HIPAA (health information privacy) documentation. It may be worth pointing out that everything I mentioned is a higher level of documentation than the desk-top documentation typically needed for training and reference.

If you're interested, PM me and I'll try to dig up some templates and examples.

steeladept:
I am pretty sure I have some Process documents as well if you want them.  They are more a template of an outcome - the results of what you are trying to do - rather than something that will help you get there, but if you are interested, let me know.

Target:
I'm not sure that you need any particular sort of qualification for this (though it may  well be an advantage)

actually being outside of the processes (ie objective) is a HUGE advantage because you can view things dispassionately

you're also much more likely to ask logical questions and focus on the why's, and to see where there are potential gaps or opportunities because you don't have anything invested in any of the processes.

A lot of processes actually contain a lot of accepted practices rather than formal processes (even ones where a formal process has existed for sometime) and mapping them out will clearly show (everyone!) where things are and where things aren't quite right

and +1 for the feedback thing.  This is really important to those who have provided input and makes a big difference to their buy in at the end...

Navigation

[0] Message Index

[#] Next page

[*] Previous page