Business Process Improvement
Business Process Improvement (BPI) with SharePoint
What is User Adoption?
User Adoption is embracing a concept, method, or tool in terms of business or operations. For use with SharePoint or Office 365, User Adoption is a measurement of success by those within the SharePoint community. Although TEDI measures User Adoption we do not focus on “driving user adoption”. Instead, we focus on making the tool work for the business practices performed by teams. User Adoption will follow as a result. Our priority in designing an effective SharePoint ecosystem is a fluid method for adding business value into team portals. This comes with providing end users knowledge and easy ways for facilitating their business process into effective SharePoint features.
When team members want to improve performance, document their process, report on results, and deliver on mission objectives they are looking for effective collaboration. The intent of collaboration technologies like SharePoint and Office Suite are to provide organizations a platform to offer this capability. Because these tools can be leveraged for any process, a technical challenge emerges on how to facilitate improving a process with SharePoint and Office Suite to satisfy my business needs quickly and efficiently. TEDI views these challenges by operation category, where SharePoint or Office 365 provides the foundation for solving most business needs. This article will demonstrate how we facilitate quick ways to translate a business process into SharePoint solutions. We will provide our audience with our approach to rapidly align a team and organization to functioning with a collaboration tool like SharePoint. These methods drive the use of the tool which will in turn increase user adoption. As more teams, leadership, and essential operations collaborate or share information within SharePoint or Office 365, they will rely on these tools for performance and thus create an atmosphere driven by social networking. When individuals hear the term social networking, they identify Facebook or Twitter as the forefront for these features. Social networking can encompass more than social forums but also the ability to drive business operations through networking and sharing data quickly. When a SharePoint workflow provides team members with forms or request for submission of tangibles, we are socializing this information to other team members. Email provides little scalability for retaining and cataloging information needed for a later date. The use of SharePoint provides a social function which automates this information sharing. Whether designing a workflow, reporting, or storage repository, we are effectively aligning your operations with this social collaborative technology. The more we perform, the more demand and thus the increase in user adoption.
Rapid “App” Designs Overview
Maturation is seen over time as requests become more frequent and complex. Our ability at creating rapid “Apps” for business solutions stems from the need to kick start user familiarity and use of collaboration technologies. We specialize in being able to quickly deliver workflows, custom lists/libraries, ASP.NET applications, and custom architectures that address the fundamental cornerstone of successful collaboration. SharePoint is not an isolated tool but a collaboration platform that integrates with many native Microsoft and non-Microsoft technologies.
Part of its success originates from the ability to integrate and share data with almost any technology. However, what makes it successful is often seen as its greatest challenge as the “how” factor is not always an easy answer. Our staff is well versed in the many methods for developing these solutions. Beyond the technical mechanics as identified below, we approach our solution designs to be didactic. In providing strong how-to, documentation, and stakeholder training, we work to mature the organization’s end user’s knowledge base. We work to provide the transition for end users to become Power Users and build much of this OOTB functionality independently. Our goal is to develop the organization into operating as a collective unit and become familiar with integrating social collaboration technologies for their everyday life.
The Future of Collaboration
Tools like SharePoint, Office 365, TFS, and Cloud Solutions will only increase. Collaboration through tools versus email will become the future of business and operations support. Eventually, performance standards will require the use of these technologies. The faster we transition staff to the collaborative mindset, the easier our ability to foster growth and provide technical solutions. Our goal is to mitigate thinking and working in the piecemeal, “email you when I’m done” mentality and grow the “sharing” via collaborative tools approach.
Rapid “App” Creation (How-to Article)
We find the majority of business processes and requests can be performed through a simple combination of workflows, document libraries/lists, site columns, and content types. This Business Process Translation (BPT) is our mechanical approach at interpreting workflow and process steps to be translated into an effective SharePoint solution. This is generally facilitated through the creation of these workflows, document libraries/lists, site columns, and content types. The creation and our translation process is documented below.
The most beneficial capability of SharePoint and other integrating tools (e.g. Office) is use on a daily basis to facilitate your day to day processes. However, many organizations do not align their processes to the capabilities of the technology. This is not for a lack of desire but a lack of understanding on how to employ quick and effective solutions that bring processes into this collaboration platform.
We recommend certain tools to enhance the process and expedite the creation of these solutions. Although not required, creating workflows quickly can be performed through K2 Black Pearl. We can create these solutions in tools like SharePoint Designer or Visual Studio, but find that to meet our “Rapid” approach method, we require the use of a tool like K2 Black Pearl.
Business Process Translation (BPT)
BPT is a method for interpreting a business process. Although not necessarily specific to .NET vs any development, configuration, or tool installation, BPT is a coined term for steps that any developer or solution designer will take. Each meeting, discussion, or reference material provided by our clients is part of the BPT. Our method is based on streamlining processes to make them work faster, more efficiently, and with more visibility. Therefore, we need to master the workflows you perform in order to enhance them. Our approach on this is a simulation of hiring a new employee to assist you in your day to day operations. We want to walk in your shoes to understand why you do what you do and identify the pain points that make the day harder. These are the bottlenecks we will work to resolve through the solutions we produce.
Above is a generic administrative workflow broken out into each of its individual steps. In order to demonstrate BPT and how we create Rapid Apps to solve business solutions we need a use case to refer to that can fit many scenarios. Descriptions are identified below
Step 1: An important request is received by our Project Manager (PM) by someone important within the organization.
Step 2: This individual fields this request and is asked to update a spreadsheet. This standalone spreadsheet contains important and sensitive information and must be reviewed by the PM’s leadership.
Step 3: The PM emails the updated spreadsheet to his or her reviewers.
Step 4: The Reviewers have a problem with the updates and request by email for the PM to again, update the standalone spreadsheet.
Step 5: PM updates the spreadsheet.
Step 6. PM sends the spreadsheet back to the Reviewers.
Step 7: Reviewers confirm it is ready and communicate it to the PM.
Step 8: The PM reaches out the originator of the request.
Much of the constraints of this process are the communication methods. Simple requests require correspondence via email which is flat and not integrated with the performance of the task. Each time a change needs to be made to the spreadsheet, it requires an email of the most up to date version. There is no effective way to store and catalog data from emails. In other words, we have not received any metadata to track and report on. The time it takes for a Reviewer to respond or for the PM to complete a request is not well documented. There is no scalability to tracking when and why the request came in unless stored statically within the standalone spreadsheet. In addition, the spreadsheet itself may have important metrics that can be shared with the group. Even if we added a Shared Drive to this example, we only gain the ability not to email the spreadsheet with each request. But there are still no metrics tracked and individuals can only operate in the spreadsheet one at a time.
The generic administrative workflow above is also broken out into each of its individual steps identified below
Step 1: An important request is received by our Project Manager (PM) by someone important within the organization.
Step 2: This individual fields this request and is asked to update a spreadsheet. This spreadsheet is stored in SharePoint which uses Excel Web Apps. The spreadsheet contains important and sensitive information and must be reviewed by the PM’s leadership.
Step 3: The PM logs into the SharePoint site and updates the spreadsheet. An approval workflow is kicked off automatically which tracks metrics (reporting capability) while also emailing the reviewers identifying that they have a document to review.
Step 4: Embedded in the email, the Reviewers receive the link to the SharePoint site which was automatically generated by the SharePoint workflow. Reviewers have a problem with the updates and deny the approval workflow request. The workflow is programmed to send an automated email for the PM to again and update the spreadsheet. The Reviewers can provide details in a field identifying why they denied the spreadsheet approval, allowing the PM to make the updates and submit again.
Step 5: Workflow is then approved by Reviewers and one approved, an automated email is sent to the PM to confirm its acceptance.
Step 6. The PM reaches out the originator of the request.
There are several key differences between these 2 use cases. First, we cannot calculate the speed in which these use cases are performed but we can guarantee that the time for the second use case to be completed is far less timely. This is because communications are controlled by the collaborative platform which creates the alerts to the stakeholders directly. There is no drafting of emails, the system provides the communications to the stakeholders directly with instructions that the other stakeholders can draft on the fly. In other words, during an approval denial, the Reviewers can write in the denial specific reasons as to why. This metadata is automatically sent back to the PM via email and is also stored within its corresponding document library for later reference.
A second notable difference is the scalability of the process in our second scenario. By using SharePoint, the initiating request can be documented and stored. This provides a research capability to determine why requests were performed. In the first scenario, this research can only be performed via email searches but runs into scalability concerns when employees leave and their emails are no longer easily accessible. SharePoint provides us the foundation for scalability behind our day to day.
A third notable difference is our ability to create reports and KPIs. Performance Indicators are our window into team performance. The workflow automatically records the timing (e.g. KPI) between workflow steps. It can also track the total time for workflows (e.g. another KPI) to be completed and we can build reports to compare and calculate these deltas. Hence providing a real time ability to see workflow status across one or many processes which can be compared to other data collected over a span of weeks, months, or years. Thus providing the ability to track the team performance and whether or not they are reaching pre-determined milestones. When the organization is mature and many of these processes are included into SharePoint, we can begin examining Portfolio Management. Due to the volume of requests around reporting, we have created a separate page discussing collaborative technologies and organizational reporting located here.
A fourth difference is accountability. In building the workflow, we would recommend thresholds of times before reminder emails are sent to stakeholders. In the event a task is pending and several automated email reminders have been sent but still no action is taken by the PM, then the PM’s leadership is emailed as to the pending task. This provides accountability in whether tasks are being completed over a span of time.
A fifth difference and a fun capability is the co-authoring functionality associated with SharePoint. Users can simultaneously review and edit documents within SharePoint in real time. In this case, this would provide the Reviewers and the PM the capability to review changes together. This is social networking at its finest, providing the ability for the PM to ask questions or engage with the Reviewers as to their initial denial of the approval.
Workflow Capture and Delivery Mechanics
How do we take the first use case and create the second use case? Our procedure is both a managerial one and a technological one. Although we cannot educate you on the specifics of our technical knowledge, we can provide how our team’s manage this facilitation. We will also provide you information of the tools we work with. In the event you request our services, one of our initial requests will be on whether we can leverage certain tools.
Requirements and Delivery Expectations
Many organizations already have Functional and Non-Functional Requirements created. If this be the case, then this saves us tremendous effort. In the event these requirements are performed, our team will review with stakeholders the requirements in performing rehearsed scenarios of new employee simulations. This is where our designers sit with end users and walk through their process and how they perform the process in the “As-Is’ state. As-if our Designers were hired on as new employees, we request to train them on how you would instruct a new employee to perform the tasks. In doing so, our Designers see firsthand how the requirements correlate with the request.
In the event requirements have not been created, this same method of new employee simulations is performed. Guiding our Designers through the “As-Is” state allows us to identify gaps, impediments, and thus functional requirements. We also hear directly from end users the pain points associated with their day to day in which our Designers can potentially mitigate or eliminate when developing the associated solutions.
Functional Requirements Translated into Technical Solutions
Once our team have a strong foundation on the “As-Is” state, they then proceed to creating what the “To-Be” state will look like. Architecture and flowchart diagrams are used in documenting both the “As-Is” state and the “To-Be” state. Much like our earlier Visio examples of both scenarios’ above, our team will document each step of the workflow via the diagram and in addition, write out descriptive analysis per step.
Note, we use an Agile Approach for development. We also look to use User Stories in our facilitation of requirements. This is because if we ever move to coded solutions, our verbs and pronouns within User Stories create our code class structure which we demonstrate using Unified Modeling Language (UML). Also, our Agile approach facilitates the ability for end users to make some requests and changes during the process versus being slated through budget to get a solution that we cannot edit during testing.
The Tools We Rely on Most
There are several tools used for creating SharePoint Solutions. Some are provided by Microsoft and some are not. Some are free and some are not. There are also many ways of performing the tasks. What we recommend are our methods but this does not mean you are limited to them.
- K2 Black Pearl
- SharePoint Designer
- Visual Studio
- Team Foundation Server
- Office 365
- TFS Online
- Various Metalogix Tools
This is our premier method for rapid workflow creation. K2 Black Pearl is an easy to user interface that allows us to create SharePoint workflow logic at much faster rates than any other tool including SharePoint Designer or Visual Studio. It is also user friendly and internal Power Users can eventually be trained for its use. Therefore, this provides the organization with individuals who are capable of creating workflows. We can facilitate and train organizational personnel on its use.
SharePoint Designer is Microsoft’s tool for creating and editing SharePoint Sites. This application provides us the ability to create workflows, content types, site columns, sites, and other business related solutions. This tool is free for download by Microsoft. We often use this in conjunction with K2 Black Pearl for development. K2 Black Pearl focuses on the workflow design but any site components such as Site Columns or Content Types we generally use SharePoint Designer or Visual Studio.
Visual Studio is part of Microsoft’s MSDN suite of tools. It’s the premier development tool for most custom development whether for Microsoft or open source solutions. Most federal organizations have access to this and is highly recommended for use with SharePoint solution design.
Another collaboration tool used for development, solution storage/collaboration, help desk and other purposes. TFS is preferred in storage of our custom SharePoint solutions.
Our development methods can be used for both SharePoint or SharePoint Online (Office 365). We will approach Cloud Solutions differently as their Multi-Tenant architect requires it. OOTB solutions, workflows, and other business related products.
Recently, Microsoft has provided its source control and ALM capabilities to the cloud. Visual Studio online offers Team Foundation Server in developing within the Microsoft cloud environment. Although this does have limitations in comparison to the standalone enterprise server version, this does provide teams with the management capabilities associated with development.
Metalogix offers a variety of tools for governance, data security, permissions, migration, and content management for SharePoint environments. Our engineers have extensive knowledge using and deploying these tools to satisfy often critical business requirements by implementing these features.
Documentation and the “As-is” to “To-Be” State
As part of our translation process, we attempt to capture through architecture diagrams and process analyses the current state “As-Is” and the desired state “To-Be”. This is done to demonstrate how the workflows are to be enhanced and set expectations on how we envision the process. The “As-Is” state is meant to identify bottlenecks and impediments within the workflow. A careful examination of the step by step process is recorded and reported back to the process owners for validation. We empirically search for gaps and issues which translate into new requirements for the proposed solution.
When we have completed our analysis including gaps and impediments within the current state, we demonstrate our proposed method for solving these issues through the new “To-Be” state. When incorporating SharePoint into business solutions, often the use of workflows (e.g. K2 Black Pearl) will allow for automation, alerts, server generated emails, and capturing or disseminating important business material like documents or spreadsheets. In addition, we can examine where metadata is captured for reporting and identifying how we have improved upon the process. It also allows us to identify new or other bottlenecks to address for future enhancements to the process or solution.
A priority of our establishment is to provide a didactic environment for use in growing the user base and adoption. Training is tantamount to the success of a project and a core focus of our methods. We divide our training by stakeholders to work closely with specific kinds of users in adapting them to their processes. This is dependent on the kinds of stakeholders we identify and the kind of solution under development. Some examples include Project Manager Training, Developer Training. Tester Training. Senior Leadership Training etc. Deploying SharePoint wholesale across the organization is vastly different from individual solutions for teams or divisions. If we develop a specific solution, we may have specific roles that are unique only to that process. Hence why our training is always tailored specifically for each solution or deployment.
Training is hosted and performed through a series of PowerPoint presentations for each stakeholder group. The intensity and time dedication of the training is dependent on the solution developed. Each of the stakeholder groups receive their own individual training guides that provide detailed how-to knowledge, links, and other vital information to facilitate their new To-Be process.
Examples of these training materials are available below for download