From contents to business context

The other day, I was having a conversation with a customer on how to make it easier to get their users to use a particular solution which they took months to build. He was particularly proud on how creative his team was in using the various content types, i.e. lists, tasks, libraries and sites to represent the different types of information that were required in their solution. When I drilled down to the challenges that users were facing, he shared that the users were complaining having to look for the right place to put the information so that the “problem” was solved. Sounds familiar?

SharePoint is a great content management tool but when it comes to context, it is lacking many features that are often necessary. The best way to explain what I mean is to illustrate the very example that I started talking about earlier.

The solution that he was building was to improve the way they handle Engineering Change Notices (ECN). Using document libraries, he could store these documents and create a workflow using lists and tasks to assign the jobs to the relevant person. The challenge comes when a user is looking at a particular content; he does not see all the corresponding or related data is associated with this data. What is required is the ability to view different content in a relational model.

The other problem is that the user only needs to see the information that is relevant at the moment not the entire lists or set of data. So when they see everything, the users get confused and lose focus. They need to see things from a transaction perspective.
And this is what we mean by context; especially business context! By context, I mean “what are we trying to achieve?” versus “what am I looking at?” And users are more interested in the “why’s” than the “what’s” because meaning incentives you to complete tasks, no matter how mundane they are.

In business terms, ECN is just a part of a bigger problem called PLM: Product Lifecycle Management. The intention is to create a single source of truth on the way products are manufactured. ECN serves to communicate to the production team on the various changes on how to make a product. The problem that they set out to tackle is called “change management”. The objective is to track:

  •  Identification of what needs to be changed. This should include the part number and name of the component and reference to the drawings that show the component in detail or assembly.
  • Reason(s) for the change.
  • Description of the change. This includes a drawing of the component before and after the change. Generally, these drawings are only of the detail affected by the change.
  • List of documents and departments affected by the change. The most important part of making a change is to see that all pertinent groups are notified and all documents updated.
  • Approval of the change. As with the detail and assembly drawings, the changes must be approved by management.
  •  Instruction about when to introduce the change—immediately (scrapping current inventory), during the next production run, or at some other milestone.

And this information has to be communicated to the various different stakeholders:

  •  Change Requester
  • Document Control Administrator
  • Reporting supervisors
  • Reviewers in charge of the different roles/processes
  • Trainers (Person in charge of training the various teams)
  • System Updates (Person in charge of making configuration changes to equipment/systems)

The business context of this solution is to get the next person to complete the appropriate task so that the entire team is aware of the necessary changes within their production process. To be more specific this requirements is best represented in the following diagram.

ECN Process

Figure 1: ECN Workflow

As you can see here, the most important role in the process is the Document Control Administrator whose job is to assign different tasks to different person to get the job done.

Here’s one way of solving this problem:
1. Create an inbox for people to submit their change requests to the Doc Con
2. Create a ECN workspace that contains all the information pertaining to a ECN
3. Use a document to store all the required information for the change
4. Assign tasks to rope in the appropriate person to assist in specific processes
5. Create an inbox for tasks assigned so that they can access the ECN details.

Let’s quickly go through how this solution works from the user’s perspective:


Figure 2: Adding a new change request

Upon entering these requests, the person in charge will receive an email with a link to his inbox dashboard in the home page of the solution, as shown below:


Figure 3: Inbox for change requests

The inbox will provide visual cues if there are actions that he is supposed to take. A single click will pop open the Change Request approval screen as show below:


Figure 4: Approving Change Requests for Action

Once it has been approved (i.e. promoted), the icon will change and now it is ready for the Doc con admin to initiate the Engineering Change Notification process.


Figure 5: Creating a new ECN

When he clicks on the icon, the following screen will pop up for him to fill in the details.


Figure 6: Creating a new ECN

He can trigger all the required or relevant approval processes and assign it to the respective person. These people will be automatically notified when its time for the necessary approval.


Figure 7: Conditional Routing Option

All the details will be shown in the ECN main form which includes all the approval tasks and related documents. Please note that it also provides visual cues on where is the current stage and what are the next steps.


Figure 8: ECN Workspace

In this workspace, it contains everything that you need to manage this ECN, including all the information, approval tasks and related document. By the default the system automatically creates a ECN document based on a standard template that extracts the details from the ECN. When you click on view, you will see it.


Figure 9: Standard ECN in Office Web App Viewer

When an approval tasks is assigned, the person will receive an email together with a link to the tasks assigned dashboard as shown below.


Figure 10: Tasks Inbox

When the person clicks on the link, he will go to the ECN workspace with his action highlighted as seen below:


Figure 11: ECN Workspace with context sensitive action

Once he clicks on the action menu option (1. Supervisor approval), the approval screen will appear and he can response accordingly.


Figure 12: Approve/Reject tasks

Once it is approved, the next tasks will be triggered and the process repeats until all the tasks are completed as seen below:


Figure 13: ECN Workspace Progress Bar

And this processes is repeated until all the steps within this process is completed. Once the ECN is completed, it will be published on the active ECN, which you can search for.


Figure 14: Search ECN with drill-down

And since the data was already there, I could not resist adding a few reports to gain better insight over the processes.


Figure 15: Reports


Figure 16: Tasks Analysis by People

Fortunately, the customer agreed with me but the question remains: how do you make SharePoint features to work in a contextual form. How do you combine all the different contents with SharePoint in the same way as you would with a relational database? To his delight, I showed him how Webparts360 does see his content as relational tables when he saw the ER diagram.


Figure 17: Entity Relationship Diagram

Or was he surprised to see the work flow diagram for each approval process was also built using a drag and drop workflow visual tool running on a browser.


Figure 18: Workflow Design Screen

Or how manageable where the solution when every single interface pages and its associated web parts were discoverable within the solution modular view.


Figure 19: Solution Modular View

For Webparts360, building solutions is all about creating solutions that are contextual in nature using a tool that is easier to use and change. By the way, did I mention that this solution built in 2 days? After all, it only uses 14 custom lists and is comprised of 33 web parts. You must be wondering how I knew? The secret, of course, lies with Webparts360 self-documenting feature which tells you how many components there is and where everything is. Why? Because I am forgetful and I don’t want to waste time documenting everything that I did (again). Moreover, I deserve some time-off after working so hard. What about you?


1 Comment

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s