views:

299

answers:

4

I have been tasked with automating some of the paper forms in HR. This might turn into "automate all forms" eventually, so I want to approach this in a way which will be best for the long term and will be a good framework as this project grows.

The first things that come to mind were:

-InfoPath/SharePoint (We currently don't use SharePoint now, and wouldn't be an option for the next two years.)

-Workflow Foundation (I've looked into this and does not seem too attractive or appropriate)

Option I'm considering at this point:

-Custom ASP.NET (VB.NET) & SQL Server, which is what my team mostly writes their apps with. -Leverage Infopath for creating the forms electronically. Wondering if there is a good approach to integrating this with a custom built ASP.NET app. -Considering creating the app as an MVC web app.

My question is this:

-Are there other options I might want to consider? -Are there any starter kits or VB.NET based open source projects there which would be a starting point or could be used as a good reference. Here I'm mostly concerned with the workflow processing. -Any comnments from those who have gone down this path?

+5  A: 

This is going to sound really dumb, but in my many years of helping companies automate paper form-based processes is to understand the process first. You will most likely find that no single person understands the whole thing. You will need to role-play the many paths thru the process to get your head around it. And once you present your findings, everyone will be shocked because they had no idea it was that complex. Use that as an opportunity to streamline.

Automating a broken process only makes it screw up faster and tell a lot of people.

As far as tools, my experience dates me but try to go with something with these properties:

  • EASY to change. You WILL be changing it. So don't hard-code anything.
  • Possible revision control - changes to a process may or may not affect documents already in route?
  • Visual workflow editing. Everyone wants this but they'll all ask you to drive it. Still, nice tools.

Not sure if this helps or not - but 80% of success in automating processes is not technology.

n8wrl
+1 I agree 100%. Make sure you understand the entire process because most form-based processes are overly complex. Definitely suggest streamlining before implementing as well. Not only will it make your life easier, your success will actually be perceived higher when processes take less time and become ultimately less complicated. Moving a broken process to an an electronic version will not necessarily make it "better" or "more efficient". It is, after all, still a form.
lc
+1  A: 

This is slightly off topic, but related - defect tracking systems generally have workflow engines/state. (In fact, I think Joel or some other FC employee posted something about using FB for managing the initial emails and resume process)

I second the other advice about modeling the workflow before doing any coding or technology choices. You will also want this to be flexible.

Tim
+1  A: 

as n8owl reminded us, automating a mess yields an automated mess - which is not an improvement. Many paper-forms systems have evolved over decades and can be quite redundant and unruly. Some may view "messing with the forms" as a violation of their personal fiefdoms, so watch your back ;-)

  1. model the workflow in terms of the forms used by whom in what roles for what purposes; this documents the current process as a baseline. Get estimates of how long each step takes, both in terms of man-hours and calendar time
  2. understand the workflow in terms of the information gathered, generated, and transmitted
  3. consolidate the information on the forms into a new set of forms for minimal workflow
  4. be prepared to be told "This is the way we've always done it and we're not going to change", and to gently (a) validate their feelings, (b) explain how less work is more efficient, and (c) show concrete benefits [vs.the baseline from step 1]
  5. soft-code when possible; use processing rules when possible; web services and html forms (esp. w/jquery) will go a long way if you have an intranet
  6. beware of canned packages (including sharepoint) unless you are absolutely certain they encompass your organization's current and future needs

good luck!

--S

Steven A. Lowe
A: 

I detect here a general tone of caution with regards to a workflow based approach and must agree. Be advised about the caveats of most workflow technologies which sacrifice usability for flexibility.

Glenn