Precision Guesswork

Continued from: Process, Procedure and Flow on 6/6/2008

 

So far I have tried to explain that the process of business is the foundation of any type of application that can be built for that business.  There is one more tool that can be very useful fo this evolution of designing and building your application.  It is called a SIPOC.  Not to be confused with Sybok.

What is the SIPOC?

When you look this term up on the net you are going to find a number of references to Six Sigma, DMAIC and such.  Trust me it is really not that complicated.  One of the best references I have on this item is here: http://www.isixsigma.com/library/content/c010429a.asp

SIPOC is an acronym that literally stands for (S)uppliers, (I)nputs, (P)rocesses, (O)utputs, (C)ustomers.  The reference comes from a method of process modeling and analysis that seeks to organize this information into one place.

Typically the SIPOC guidance will usually tell you to take a high-level process for this type of analysis but it is also useful at a more detailed level.  At this level where the process is broken down into it more or most basic for you can see the interactions of people, process and tools, like data systems

For your pure enjoyment, or a reason to laugh at me.  I cleaned up my SIPOC utility and put it HERE with the items for my previous process drawings in it.  I also had to post another drawing with the corrisponding numbers for the process references.  It is built in APEX which was built in APEX and helps me to build applications in APEX too.  Circular Definition, anyone?

Anyhow, I find this tool really cut to the chase in determining the process and the key elements about the process and its users.  When you take this items to a good level of detail the system interactions with the process and the people involved really have a way of standing out and it make the task of designing the application and the underlying datamodel a bit easier and more consistent.

Updated Note:  Please keep in mind that the SIPOC Application has an output that I was still experimenting with and haven't yet perfected.  Also, feel free to add your own rows and see how this (very basic) application works. jda.

Update: 06/15/2008 : Got word the embedded files in the Blog were messing with the APEX Blog Aggregator so I went with poting a thumbnail with a link to the file instead.

Continued From: Beginning Systems Analysis on 5/8/2008

 

  Whatever name you or your organization uses for this item, the foundation of a business data system is the Business Process.  Just about every application that can be concieved has a process of use that is associated with it but the underlying difference between a utility application like a "DVD Catalog" and a business App is that the process that drives its use is more than just the process to use the application itself.  So the Business Process is the first key area that has to be analyzed when attempting to build an Application that fills or automates a business need.  In some cases the process that is originally mapped is the old process that involves all of the hand-offs that many different functions will contribute to.  Mapping the process can be done any variety of ways from note pads to tools designed for process modeling like MS Visio or others.

  Recently I had the opportunity to go over a version of a process that I had seen in several organizations that centers around proactive safety and hazard mitigation and documentation.  This discussion goes back to the previous series on early adopters and such where the person detailing the process was, by every definition, very passionate about the activity and the surroundng circumstances.  By the way it was also a good refresher on how to tell a salesman from an advocate (or Evangelist), the salesman could never sound that kind of sincere without also being an advocate.

  So the discussion progressed and along the way I took abunch of notes on the steps involved in this particular process.  It is not that complicated, but then again the best trips from one point to another are the ones that make sense and don't go into too many twists and turns away from the end goal.  So here is the first an most common process model that comes from those discussions. 

 

Update: 06/15/2008 : Got word the embedded files in the Blog were messing with the APEX Blog Aggregator so I went with poting a thumbnail with a link to the file instead.

Today I got the opportunity to attend a free web seminar hosted by Doug Gault of HOTSOS.  The topic is all about Performance Tuning of Application Express. 

 

Doug opened up with a topic that is near to my heart of knowledge and understanding of your environment and, especially, your target users.  Which leads into the idea that an understanding of the way APEX is installed and how it works from the perspective of how it processes the application and its elements. 

 

Just about all of the major best practices that I have seen in different documents and presentations plus a few items that are new to me. 

 

Some of the good skils and activities involved for me are 

  1. re-inforcement of a proactive monitoring of your applications and the APEX System/Applications

  2. the use of tools that are already a part of the APEX system

  3. using more stored procedures

  4. a good process of identifying and eliminating potential causes of a performance hit using a variety of tools that are readily available to anyone in the community.

 

In all things this time was well worth the time to participate.  The slide deck and presentation is available at www.HOTSOS.com go to events and then webinars.

  Blame my particular form thinking but I like to deal with business issues surrounding the IT industry.  By nature, when I see a problem or potential benefit area I look for ways to either solve the issue or to act on the opportunity.  Most times it is a good thing, others it just becomes 'Tilting at Windmills'.  It is fun and entertaining in any event.  (Keep in mind that my version of fun may not directly corrispond to yours, or the dictionary)

 

  With Application Express, XE, SQL Developer, and any number of other tools, our community has come to a point where the ability to attack a business need has definitly increased.  The APEX platform gives us a very concise and easy to learn Rapid Application Development environment to not only create an application but to quickly realize the benefits of that effort.  I came to APEX, html-db at the time, community when I saw that this was the type of system that could solve a lot more than just one or two issues.  I saw the potential to reap benefits that I previously would spend days and weeks just formulating the design for in other tools. 

 

  So since anyone in the community already knows this stuff why am I re-iterating it like a broken record?

 

  Without using any cliche, or attempting to do so, my observations of late have been that there is a whole lot of talented developers that can build just about any functionality into an application that one might desire.  There are books on how to do this.  I own more than a few of them now.  What is missing in all of this is the idea that systems development begins before you actually write code or build pages.  APEX lends itself very well to build first methods, but in this sense it becomes increasingly easy to build an application that is obscure, inflexible, and/or unsupportable.  This is the same with any tool you use and you can certainly do worse in most cases with other, hard-coded, systems.  Without some base thought processes and documentation, a new developer has a higher risk of losing their way or not being able to pull apart a broken component to analyze it and fix the issue.  Another fun result is that the progression of application developement is pretty predictable as the APEX platform evolves and as the individual developer increases in skill as well. 

 

  This topic is designed to cut the process of evolution short and get developers on the right track to defining and building applications that are scaleable, flexible and flow in such a manner that they become almost intuitive.

Now I know that this BLOG is being read by quite a few people.  I can see the traffic Statistics in my console.  I also know it is in my nature to be direct in my thoughts and oppinions, sometimes Blunt is just the beginning how flatly some of these thoughts hit the ground.  I also have no qualms about admitting when I am wrong or appologizing to those I may happen to upset, even though I never actively seek to do so.  So if there is an issue with this space please bring it to me directly there are messaging tools on this site that allow you to post your thoughts in relation to my own to me and to te world.  Use them, that's what they exist for. 

 

So why put this out.  Because I care and I know that there will be time when I open a can or worms intentionally to spark a conversation or bring a point home.  Trust me when I say that I don't shine a light on any person or thought without bringing my own practices into it first.  Having perspective means knowing that you may have missed something along the way.

 

Regards,

 

Jason