Documenting Business Process

anyone ever do that?
any example?
what tools that u use?

currently i need to document business process while my background is programmer not as analyst

thanks,
erick

PS: sorry if i post at the wrong forum

Shouldn't this be a task for a business user? At the company I work for, we implement business rules created by the business. While we do our best to document them as we implement them, the business should also be outlining what the process should be.

Not sure about any tools. I would be interested in hearing about any.

thanks for the reply

Shouldn't this be a task for a business user? -> yes..

but now we are multitasking and i want to learn it too by doing as best as i can

While we do our best to document them as we implement them -> document, any standard format? or example? to document it, u using Excel? Visio?

Mostly in Word documents. We're actually just starting to form idea as to how to document business rules, application technical specifications, etc.

Quote:

---

Originally Posted by kasracer

Shouldn't this be a task for a business user?

---

Yes, absolutely.

I actually gave it a shot once just to see what all goes into it.

I got so bored doing this documentation that I started hunting around for a bridge from which to hurl myself. Fortunately, this is not something I have to do, and I consider myself to be a very lucky man because of it.

Fortunately, this is not something I have to do, and I consider myself to be a very lucky man because of it. -> bullseye :D..

i like to learn something but when do some documenting, i found it so hard :D

and beside my opinion is if u can do like capture the whole business process, u are like system analyst and it's the position that above the programmer

I have my own software house - so I wear all hats.

When we start a new project with a customer it's always after a sit-down meeting to discuss needs. If the process has never been automated - we take copies of all paper documents. Either way we get into the details of office procedures. The best software fits into existing office procedures effortlessly. That's not to say that some office procedures aren't in need of adjustment - sometimes that comes out also.

But in the long run - after this initial meeting - and lots of paper notes - we start the project. I find no reason myself in turning these notes into electronic documents - as in the long run they are worthless...

Every single project I have ever worked on has followed an iterative [edit]I did not mean interactive![/edit] development cycle - you get 70% done - show the user - redefine 15% of the original specs - go back to coding and get 80% done - show the user - refined 8% of the specs - back to coding - get 90% done - show the user - it goes live...

And you spend the next year adjusting and enhancing...

Quote:

---

Originally Posted by kasracer

Shouldn't this be a task for a business user?

---

In theory the task should be one for a business user, but in reality its often the programmer documenting the business process. :o

The business user then reviews the document and gives his feedback on it.
:wave:

The business user then reviews the document and gives his feedback on it. -> and the world will be brighter again :D

ok..i think i have enough feedback..thanks for all replies

I use process maping tools (Visio), workshops and ask the business to review the initial recomendations document and build on that.

I am amazed that there are actualy people that just code! where i work there is no one person that just codes.

dav

I'm currently doing what Szlamany described, but there is no standard process where I am working, so I am doing everything in Word. Originally, I kept everything as paper notes, but paper notes have a problem: You can't edit them. This means that I would fill notebooks with scribblings that made sense at the time, but often made no sense later on. I couldn't go back and flesh out an idea, so I had to start the idea over on a new page if I wanted to explore it more thoroughly. Eventually, after going through stacks of note pads, I realized that it simply made more sense to keep everything typed out. By doing this, I could relate topics more easily, update topics in place, expand on topics in place, etc. Furthermore, since I can type far faster than I can write, I am more thorough and quicker on the computer.

Other than that, we have no standard processes and no documentation. I am working (at least a little) on both.

yes, but i have no idea what would be documented..

Davadvice said VISIO, i get an image documenting it with a Diagram.

i'm already used VISIO, and RATIONAL ROSE..but it seem so technical and only system analyst and programmer that understand about it

Furthermore, since I can type far faster than I can write, I am more thorough and quicker on the computer -> Shaggy, than u will write like a story then??? with everthing describe in there?

some example maybe?

If you are talking about the content - the I feel that "paragraph-like" descriptions of what the software will do are the best. They leave out ugly details like "text box a" here and "command button y" here and this happens when you click "z".

I've gotten to the point where I don't even want conversations with users to go to the point of "how-to-implement". It's all about "what-to-implement" and the "how-to" details are what us programmers are designed to deliver.

hm, it's about Documenting Business Process..

maybe like this is how the old system do, this is the new one..not in detail like sz said..

I've gotten to the point where I don't even want conversations with users to go to the point of "how-to-implement". It's all about "what-to-implement" and the "how-to" details are what us programmers are designed to deliver. -> agree with this one..but what if the programmer is ask to document the Process in User perspective? some words/picture that just by reading/seeing it, it can make user understand

PS: found a S/W, SmartDraw..need to try it :D

I used Smart Draw at college, good little application. think it was UML we used it for, not sure though

In My role we include the user from the very start of the project to understand what they think about the ideas we have throughout the cycle of the development. one of the reasons for this is that they normaly know what the need to do as they are the experts and it is easier to get buy in from them when we do implement.

maybe worth looking up six sigma as the life cycle used in that may be of relevance


Thanks

Dav

Quote:

---

Originally Posted by erickwidya

some example maybe?

---

I don't think that would be wise. In an attempt to get the user group for my current project to actually consider a meeting, I described the process I was working on, the design so far, and the issues that still needed to be resolved. It was a story. A six page story, fired off in short order.

I've just spent today writing more stories. One per form, for reasons that are a bit hard to explain. However, a better example is the robot brain I am working on as a hobby. Being a hobby, I could only work on it every now and then (an hour or two every evening, and much of the last two weekends, but still....). Furthermore, being a brain, it is not a single project, but many. There is one module that takes requests for the hardware, queues them up, sends them to the hardware, broadcasts sensor readings, maintains a dead reckoning position, manages the mechanics of turning to a desired heading, etc. Another module checks the dead reckoning between sensor reads, and organizes, validates, and stores sensor readings to a database. A third module, on a different computer, will turn sonar echoes into points (filtering stray echoes), assembles points into objects, looks for gaps between objects, and requests that yet another module direct the hardware to investigate regions. And there are at least three other modules that are in some state of design and implementation. Eventually, I realized that I couldn't keep track of what each module was supposed to do such that I could manage edits and features of each module. By the time I got one new feature implemented, I had to re-learn where I had left off of another module.

Some of these modules now have a dozen pages describing what has been done, what needs to be done, and why. Many of them also have documents of thoughts on what could be done with a module, and how to implement it. The documentation is going to be bigger than the code.

Some of these modules now have a dozen pages describing what has been done, what needs to be done, and why. Many of them also have documents of thoughts on what could be done with a module, and how to implement it. The documentation is going to be bigger than the code. -> very agreed..

aaargh soooo hard...

well i must learn it immediately

thanks all