When the first business systems were developed using computing technologies, the interfaces to those systems were very literal and direct interpretations of the underlying technology. Punch cards placed into a machine contained punches that represented the core of all computing technology, a bit, indicating a binary value. The way the user interfaced with the machine, and how the machine interpreted that information was very close. Punch cards were a literal interpretation of bit based computing.
Then we developed various software based layers that hide that complexity, so that the information the developers entered at that time was first interpreted or converted into language the machine could understand before being used. “Machine” language such as MASM with commands such as “push” and “pull” still closely reflected the way the underlying technologies functioned, moving bits, other programming languages were developed that were further abstracted from the machine layer.
Then in the late 70’s to 80’s along came various flavours BASIC, a language that was "so easy to program" that some programmers feared that development was so easy they would be out of work. The technical nature of programming meant that never happened of course, but even BASIC only provided a very basic interface and limited design options. The interface design was based on what was possible rather than best choice, and just getting software to function and meet requirements was the major challenge.
This is now not the case. We have a wide variety of ways of presenting the same information to our end users, a great deal of flexibility in how we decide to support business processes, a wide variety of “development platforms” that remove most of the repetitive work involved in developing systems and allow you to focus on core logic and interface and system development. No longer are we limited by command line interfaces and restrictive toolsets, our freedom to design systems today means we can focus on how the user interacts with the system, as they move through a business process, and let this guide us in our toolset choices.
This means that there are a great variety of ways to achieve the same objectives, a large number of ways to support the same business processes, we are at the point where we assume the vast majority of the underlying technology is going to work, we spend more time assessing different technologies and approaches to see which one is the best fit for the current solution.
SharePoint 2010 represents an approach that has been tried before, a singular portal with a comprehensive set of tools supporting multiple business processes. Platforms such as Plumtree were portals that added an additional layer of functionality over isolated system development, allowing you to share identity and interface with multiple systems in a singular web portal. SharePoint 2010, in my opinion, is the first platform however that provides sufficient diversity in toolset and approach to truly support a wide variety of custom business processes. No longer are we simply replacing older systems with newer technology, through our architectural and toolset choices, we are actually increasing efficiency in the workplace and reducing the amount of time dedicated to each supported process. Measurable improvements in efficiency.
This has led to two focusses in systems development, one focusses on the technical components of the solution, the other focusses on the client side. The technical analysis of the system answers the questions “How are we going to make this work? What tools do we need and how are we going to configure them?” The client side of the system asks the question “How is the client going to most effectively be supported by the system? How can we improve the business process as a whole?”
The best way to understand the value of these two approaches is to look at the systems that result from a focus on each area.
We will take a look at a hypothetical internal Vacation Request System used by a company to support the employee vacation approval process. Fundamentally, the system requirements are:
1. Employee can fill out and submit form.
2. Manager can approve or deny request.
3. Human resources can approve or deny request.
We will first take a look at the system that results from a solely technological approach, and how each of the three user groups mentioned above interacts with the system. We will then contrast that with a system that uses the client centric approach, the tools available to the user, and how they interact with the system.
We will then look at a hybrid system that combines both approaches.
Technology Centric Design
The first SharePoint Vacation Request system that we are going to look at is one whose focus is on the technical solution. As soon as requirements are gathered, the tools needed to support the core system, a vacation request form, and their customization becomes the focus.
We will look at the way this system works by seeing how these three user types interact with the system:
1. Requestor
2. Manager
3. Human Resources
Requestor Actions
1. The requestor logs onto SharePoint, and locates the centralized Human Resources Forms Page:
2. The requestor clicks on the “Vacation Request” link. The vacation request InfoPath form opens up, the requestor fills the form out and clicks “submit”. A workflow notifies their manager that a request has been submitted. If the requestor has any questions about policy or upcoming projects that may affect availability, they email the appropriate person to get an answer.
Manager Actions
1. The manager receives an email notification from a workflow that the Vacation request form has been submitted. The manager clicks the link in the email to open the form.
2. The manager reviews the form information, cross references it with upcoming project plans and schedules, and can approve or deny the request. If the request is denied, the original requestor is informed. If the request is approved, a workflow sends an email to the HR group informing them of a manager approved vacation request.
Human Resources Actions
1. The Human Resources Department receives an email informing them that a manager approved Vacation Request has arrived.
2. The Human Resources person responsible for the Vacation Request assigns themselves the request.
3. That person then cross references the time tracking and payroll systems to confirm the requestor has vacation time available, and then approves or denies the request. A workflow informs both the manager and requestor of the final status.
4. If the request is approved, HR updates the time tracking and payroll systems to accurately reflect entitlement balance after approval.
Summary
What’s wrong with this system? Absolutely nothing. It meets the core requirements defined by the client, and it successfully supports the vacation request process.
The only question I would have for someone who approaches SharePoint development this way is “Why are you using SharePoint?” There are lots of development platforms, .net, Java, open source that allow you to develop isolated form based systems such as this. Why choose SharePoint?
You may point out that in SharePoint, you can experience rapid development since the security and so many other components are already flushed out. This is definitely true for simple systems, but, as anyone with real world experience in developing InfoPath based systems knows, as soon as you get to intermediate or higher complexity systems that require customization and complex workflows, you lose that time savings.
So for medium to high complexity systems, there is no development speed advantage over using isolated development approaches for form management. So what advantage can SharePoint provide? Let’s take a look at a system developed using client centric design to find out.
Client Centric Design
The client centric system differs from the technology centric system as the focus is different. Client centric systems focus on how the client currently completes their job, the entire business process, from start to end. It considers what tools and information a client needs to be able to complete their task, not just the core toolset needed to meet requirements, but supporting tools that increase the user’s efficiency when interacting with the system.
Let’s see how this affects the user experience:
Requestor Actions
1. The requestor logs onto SharePoint, goes to the HR Forms page, and sees the following:
The HR Page has the most common forms and documents on the front page of their site for quick access:
The HR Page has a web part that filters on the current user, and displays the current users banked and vacation hours balance:
The HR Page has a view of a centralized project calendar that allows the requestor to quickly see what upcoming projects they are assigned to:
All of this information is in a centralized area to allow quick access to all of the information the requestor needs to fill out the vacation request form. No need to email the project manager for upcoming assignments, no need to log into the time tracking system to find out banked hours balances, no need to email HR for any other questions.
Already, we start to see some of the increases in efficiency this approach can have, with a requestor not needed to spend time sending a question, and the supporting resource doesn’t have to spend time researching and responding (project manager or HR person).
2. The requestor fills out the Vacation request form after cross checking their availability and submits. A workflow informs their manager of the request.
Manager Actions
1. The manager receives a workflow notification that a vacation request has been submitted. The email they receive has two links. One directly to the form, and one to the HR forms site. When they click the link to the HR Forms Site, they see a view very similar to the Requestor. The difference is the "Person Selector" on the banked hours web part:
This allows them to select the requestor who has submitted the vacation request to them, and both view the banked and other hours for that person. It also updates the Project Calendar to only include that requestors projects. The project manager does not have to log into any other systems to determine if they can approve this request, the information is all available on the HR screen.
2. Based on this information, the manager approves or denies the vacation request. If it is denied, the requestor is informed by workflow. If it is approved a workflow informs the HR Group.
Human Resources Actions
1. Human Resources receives a workflow based email that has two links. One is directly to the form submitted by the requestor and approved by the manager. The other is a link to the “Human Resources Vacation Center”. Here is what they see:
The items that appear in the Vacation Requests section are vacation requests that are either unassigned, or assigned to the current Human Resources Person. This gives them immediate access to the two form types they are concerned with:
They can also cross reference the Vacation Calendar, that has ALL vacations listed for employees so they can be sure their are no conflicts for key resources:
And they have the gadget we are already familiar with to cross reference banked and other hours:
2. The Human Resources Person first opens an unassigned form and assigns the request to themselves. They can open the form from the workflow email or they can open the form from the “Vacation Requests” section of the page shown above.
3. They then cross reference with the vacation calendar and the entitlement hours to determine if they can approve the vacation request. They click "approve" or "deny" on the vacation request.
4. Both the manager and the original requestor are then informed by workflow of the success or failure of their vacation request.
Summary
Just as the technology centric system did, this one meets all of the original system requirements. By having a client centric approach however, more effort was made, right from the design stage to consider the following:
1. What tools does the current user need to finish their job?
2. What information does the current user need to finish their job?
By using this approach, we not only create a core system that meets requirements, we are measurably improving the efficiency of the Vacation Request process, removing the need to use external tools or communicate with other team members in order to be able to complete the request.
This system is certainly a better system from the solely technology focussed approach, but is it the best we can do? And it definitely leverages more of SharePoint’s abilities, along with effective solution design, to measurably increase the efficiency of the Vacation Request Process. But are we at an end point?
What if we were able to combine the two focusses? What if we spent an equal amount of time on BOTH the client centric analysis and THEN the technical components? In other words, we complete client centric design and then present that design to the technical team for further improvements? Let’s take a look.
Client AND Technologically Focussed Design
The first focus discussed in this post was the technology centric design, showing how considering the technical solution early and consistently throughout the design and development process can lead to a specific resulting system. One that technically meets requirements (it works) but is not really an improvement on existing systems when considering efficiency, and certainly doesn’t leverage SharePoint abilities and tools.
The second approach showed how understanding and defining the business processes first, then asking the client not just how the current system works, but also how they complete the entire Vacation Request process from start to finish improves system design. What information do they need? What works? What doesn’t? This information is then used to design the system based on a client centric model, obeying the key tenants of good system design:
1. Give the user all of the information they need to support the process.
2. Give the user all of the tools they need to support the process.
3. Don’t give them any information they don’t need to complete the process.
4. Don’t give them any tools not related to the process.
This system results in real measurable differences in efficiency in the Vacation Request process. But we can take it further. Once the system architecture and design has been determined, the architecture can be reviewed by the technical team for further improvements.
So, a technical team reviewing the client centric system design may say:
1. We have a few read only connections to external systems to allow information review. Why don’t we replace them with read/write connections and automate some of the manual tasks?
2. We can provide the information supplied by the Available Hours web part and the Payroll details web part right on the infopath form. That way, the user doesn’t have to refer back to the web parts for information, its right in the form as you fill it out.
3. We can automate the HR Vacation Approval tasks using these read/write external system connections, so that when an HR person approves the form, both the time tracking and payroll systems are appropriately updated as soon as the HR person clicks “approve”.
4. We can create a vacation trending chart that uses real time data to show vacation request history:
These are all great technical ideas that further increase efficiency and reduce the amount of effort needed to approve a vacation request.
So, this final approach based on completing client centric design first, THEN having an expert technical team provide recommendations and suggestions gives us the best of both worlds, effective client centric design that leads to improvements in processes and higher client satisfaction, along with technical solutions to key areas to further enhance those goals.
So why isn't this development model followed by more SharePoint solution providers? There are some outstanding examples of client centric design being built right now. Why isn't client centric design being used more often throughout the SharePoint development industry? Why do we still see production level SharePoint systems that resemble the first Vacation Request system example more than the second? The next post will examine where those barriers came from, and how to challenge them.
No comments:
Post a Comment