Just another WordPress.com weblog
I presented this topic during a webinar on Wednesday, April 18th. It’s the methodology we have employed here at Mytech and a short demo on how we are using XSOL to capture and engage with our processes.
http://www.mytech.com/media/discussions/420-process-mapping-for-small-business.html
I was pleasantly surprised this month when I read our Culture Experience article in our company newsletter.
http://www.mytech.com/news-a-events/news/419-mytech-culture-experience–april-2013.html
What our VP of Sales is saying in this article is that our company is transforming in the way we think and do our jobs. This is exactly the “subjective measure” I have in my quarterly goals – to have a sense of process engagement. This affirmation of our efforts is wonderful news and means we are on the right track and change is happening. We are focusing on HOW we perform and deliver our goods and services!
In two weeks, I’ll have been with Mytech for six months. My first two quarter goals were to implement processes for product order management, the vendor return goods process, our sales to project hand off process, a process to add users to our premium HaaS and Services offering, and our process to change processes. I mentioned our compliance methodology in my last post; this is managed by our process for changing process. Once our managers or coaches have signed off on a vetted process, they then have one week to work with their staff to train and have staff members sign off for compliance. By compliance to our vetted processes, I consistently coach and talk about what that means in order of process engagement. We consider these sign offs to exist like any other certification that goes into an employee’s HR file. They are fulfilling a role for a specific process and their employee certification records include process “certs” for their role in any given process. Once we have a process signed off by everyone, the work really begins. Employees are coached to have a keen eye on how their efforts affect the processs; they should be asking themselves if someone were to sit in their seats, does our process documentation provide the right information, does it clearly make sense? It is by asking these types of questions, that would prompt a user to raise a request so we can have dialog and capture the new information. Sometimes this is just simply adding additional instruction and sometimes these requests would result in a completely updated version and that would require updated compliance “certs” for all roles.
Our first version of our sales to project handoff process has been vetted and approved; we have begun training the entire staff to ensure consistency and compliance. Since we are touching so many areas of the organization and it is imperative that we capture the hand-offs and ensure that all the information is collected at the appropriate times. Looking at the high level stages (stages contain tasks and decisions and information at the granular level) in the diagram below, I am certain that as we move forward, this is going to change quite a bit.
I have set up our process site to be quite simple. It’s SharePoint site that I manage. Simple instructions to guide our folks and the ability to see what we are currently working on. The image below is what our site looks like today:
As I wrap up this quarter, I will be working on some internal processes not yet defined. Looking forward to my next updated in another month or so!
Gone are the paper copies of process maps. I have gone high-tech. I have two new 50” monitors on my office wall. This certainly saves me time from printing and taping up paper all over the wall. Our Product Order Management process is now in its second version. This means that staff members own their processes and are suggesting improvements! The Sales-to-Project process is a few days shy of being approved. This one is qualifying leads and working with Solution Design to deliver a fully prepared quote and statement of work.
Through process capture and design, I am learning every aspect of our company’s business. In capturing process with various staff members, I find that listening is the most important aspect of my job. We have been working on designing our Sales-to-Project process for several weeks and are now drilling down on the task level of each stage of work. While setting up the process, the convention of descriptions and conditions must be consistent, so how things are described is very important. At times one individual is saying the same thing as someone else, but the semantics are different. It is my job to interpret what everyone is saying and putting it into our process capture and documentation tool (XSOL).
All in all, this is a process around process. We are creating an environment of process-centric business. All staff will have a watchful eye on HOW they conduct their business and perform. We have added a compliance piece to the process model here. Once we have agreed on a process and have fully captured it, our coaches and managers sign off that they have reviewed and understood the process as documented, and are engaged and will humanize any exceptions first and follow up with a change request whenever something deviates from the documented process. This closed loop will ensure our processes are living and changing as we grow and change.
Two months into my new position and folks around here are used to seeing my office wall decorated with large printouts of process flow diagrams. I have had many insightful meetings and conversations with most of the staff and am delighted with the level of enthusiasm and effort these people pour into their jobs every day. We continue to build our process models in XSOL and while I still like to print out large maps and see them physically on my wall so I can mark them up with markers during impromptu meetings, we do have everything easily accessible to all of our staff. Our users can access our online process documentation via SharePoint. These documents are the html pages with drilldowns that I demonstrated in earlier posts. I also have made available my processes documents that are just works-in-progress so anyone can see what other processes we are currently building or changing.
The “inside sales-to-service” process has evolved into the “product management” process and has been in place for almost two weeks and we have found a few bumps as I expected we would. We have some workflow issues from our ERP (Enterprise Resource Planning) system and are addressing them and working around where we can. There was also a problem with how we captured management of a service ticket when an order is partially canceled. On the other hand, a few tickets were raised due to good critical analysis on the part of the users. Some have already taken to critical review of their own processes, applied them to our documented process, and submitted subsequent tickets on my CAB (Change Advisory Board) for me to address them and update the process to improve the flow. I am planning a follow up meeting with the collaboration team to revisit the process flow together and fix the issue around partially cancelled orders.
I am nearly ready for round two collaboration (still designing this with the Board of Directors) on the “sales-to-project” process. Original plans indicated the focus would be on the new services offering, but as this progressed, I have determined that looking at the entire sales to project process would work much more effectively. We want to break some of the processes down to simpler components so change becomes easier; however, I am finding that this larger approach is giving me a better view of the organization. As I get better understanding of this, the processes can be broken down then with more certainty on my part.
As we continue to progress on process-centric thinking, I want people to own their processes instead of just following them. Users should know that the process is there to guide them, and they are here to manage, improve, and monitor the process with vigilance. If something occurs in the process that is not currently captured, then we have to allow for the exceptions. Our answer is currently “humanize the exception, and automate the norm.” If the process gets stuck, we need our people to pick up the phone and own that issue until it is resolved and then a change management request can be raised afterwards to fix the process details.
The Beginning
It’s been just over a month since I started my new job and I have a year end goal; to define, capture, and implement two predetermined processes in the ogranization. Through some discussion with the Board of Directors and the Coaching team, we have determined that the inside sales to service process and a new initiative for a VIP bundled service package offering will be my focus until year end. Within the new service package offering, there is a design stage that should be its own process because it is followed currently in other areas of the business. I am optimistic that we will complete all three processes by year end. The tool I am using to capture and document, of course, is XSOL.
Collaboration, Collaboration, Collaboration
So far, we have had two round table discussions looking at our inside sales to service process with the users who are involved in the process and I have followed up individually between the round table discussions. We are going to provide an automated client notification email at specific stages in the process to improve how we communicate progress on a customer order. We will have our third and final round table next week to review the documented process before we “flip the switch”. We not only captured current process steps, but we will also turn on the email notification workflows and start monitoring and measuring per our captured and documented process. Which brings me to the documentation side of XSOL and how it can be used.
The output documentation can be created in Word, Excel, .chm, or .html. The Word document is useful to print out and provide for review and markup by users, but the best use of the documented output for me is the web page (html) output. With html, we have drill down capability at every stage and task level. Since I cannot post our internal process for the general public, I have updated the “Process Mapping Explained” document from my last blog post and am going to use it to show how I am approaching process capture and documenting of our three processes here at Mytech Partners, Inc..
Here is the process model in the Flow Diagram mode:
This is flow diagram form and can be completely edited here
And there is another design mode that is a tree designer and can be udpated there as well. Note the picture below:
Any changes here are updated in the flow designer screen as well
Once the team has created a flow that everyone agrees has captured the process in enough detail, we are publishing our documents to our SharePoint site so our staff can access them easily. The output documentation for this example will show the drill down in the html document. If this were one of our internal processes, a user could simply click and go and get all the tribal knowledge we have captured in the process and follow clear and concise instructions. Note the next three screen shots will show how the drill down shows addtional notes and information.
First, we will drill down on the stage “Define Stages of Work”(keep in mind, this stage could be called something like, “Receive Customer Order”:
As my mouse hovers over the stage, we see a dialog box appear that instructs the user to click on this to drill down
Now, we are in the stage flow area that shows the tasks within the stage and we can drill down, noting that when I hover my mouse, I see the dialog box again instructing me to go to the details about that particular task:
Now see the information we put into the process – instructions, including a screen shot of how to insert a link (could be a screen shot of an ERP data entry screen):
What do we do once we capture the process and provide access to the documented output?
In ITIL (Information Technology Infrastructure Library) fashion, I have created a Change Advisory Board that allows users to log change requests to the vetted processes. Upon review and discussion, we update our process and resave the updated document (if process change is approved – it is critical to establish guidelines on what information must be included in the change request) to our SharePoint site. This will make process changes manageable and fairly flexible to change.
I look forward to my next udpate; I will provide some ongoing feedback around the change requests and how the year end plan is shaping up!
