In this post, Scott Os of Synaptix Group will follow-up his recent post on what is a Center of Excellence (CoE), with information on how to establish and staff the CoE, providing you with supporting PDFs to get the process kicked off right.
Let’s say you’ve read about the importance of a Center of Excellence. On the road to your Digital Transformation, you’re now wondering, “what do I do now?” There are many things to consider, the various roles, responsibilities, and use cases that need to be defined, software and personnel costs that need to be reined in and stakeholders that need to be informed.
But where do you even begin?
That’s the premise of this post. I’ll talk about the structure, roles and responsibilities of a newly formed CoE as it relates to your company’s progress through a DTM Maturity Model, with suggestions on a path for how you can, not only create such an organization, but create the foundation to accelerate change while taking full advantage of your company’s Digital Transformation software investments.
General Guidelines
A CoE can be a service organization that provides expertise across projects in a ‘shared services model’. The function of the CoE is to drive standardization of quality products, architecture and governance policies, as well as processes across the enterprise. Leveraging a centralized management and automation platform for processes, consulting, and support services, as well as delivering leadership and advocacy to help the organization improve business outcomes.
The true value of the CoE will be around participation and the broader strategic efforts within the company. To accomplish this, the CoE needs to have strong alignment on business goals/strategy and the CoE mission. Additionally, the CoE must focus spending on the future of the organization, not just on the “squeakiest wheel.”
CoE Roles & Responsibilities
A component of the CoE charter describes the interaction of the CoE and the Steering Committee. CoE Leadership will be driven by Strategic Business Initiatives approved by the Steering Committee, and will either implement the strategic elements, or work with Project Managers & Architects to implement the policies, procedures, best practices at a more tactical level.
The CoE would be staffed with people who bring domain expertise about the business and technology. These should be from the population who run the day to day operation of your company and who are directly affected by the changes to any systems or processes. They are the people who know how changes will affect staff and what value they could deliver.
Keep in mind, this team will create a standard methodology and best practices to bring consistency and leverage to development projects. In other words, what’s learned from the initial implementations will set the precedent on what mistakes to avoid and how to accelerate adoption and change within your organization.
This added experience is the gem for creating a CoE: by creating the lessons learned and best practices, you’ll reduce the chances of wasted effort and investments in software and personnel.
In the larger context of the company’s continued Digital Transformation on the path to higher DTM Maturity, throughout the execution of the plans put in play by the CoE, the organization is creating reusable assets and a playbook that would be leveraged in the future by other departments and project teams.
Does all of this sound too big to take on?
Fret not! One of the key advantages of the CoE is that it can initially be built on a small scale, with minimal incremental expenditure. As its value is delivered to management, the staff, and individual project teams, it can iteratively evolve and scale up its resources, services, and capabilities. The CoE model can also be a critical asset for distributed organizations, providing centralized processes, infrastructure, and reporting.
Roles and responsibilities will vary depending on CoE structure and budget, but you will generally have resources that fall into one of the following four categories:
- CoE Leadership
- CoE Core Team
- Project Team(s)
CoE Leadership
CoE Leadership typically consists of the following:
- Executive Sponsor(s)
- Champion(s)
- CoE Manager
The Leadership team provides the executive support and governance to project teams. Because both are represented in leadership, IT and Business work as partners in project delivery.
CoE Core Team
The CoE Core Team is comprised of the following:
- CoE Manager
- Program Manager (Optional or could be the CoE Manager)
- Enterprise Architect
- Solution Architect(s)
This team handles demand and intake from project teams. They are tasked with standardizing the delivery process and performing the value-add services of the CoE. They own and improve best practices and methodology, enable project team members, deliver proofs of concept, and participate in program/project governance.
Project Team
Project Team(s) consist of the following:
- Project Manager
- System Architect(s)
- Business Architect(s)
- SMEs
- QA/test
Project Team(s) manage and drive the project on the ground. They are responsible for the day to day deliverables and scope and delivery project outcomes according to the best practices and methodology determined by the CoE.
One of the most effective tools that should be employed while constructing the CoE is a responsibility assignment matrix or RACI chart. This is a very useful tool during the formation phase to make certain all is covered and also during the operating phase to make sure nothing “falls through the cracks.”
Here’s a problem our customers face often. They buy DocuSign and know they can use it to streamline their document-based processes, like a self-storage occupancy agreement. But, they’re not getting much use of it since it means teaching their staff to learn a whole new tool, with its own interface, lingo, and process quirks, namely DocuSign.
Most customers prefer to have a simple HTML form on their Intranet, already used by their staff, to collect name, email and some relevant info about a customer, have it populate in a DocuSign form and send it out for signing. And they want it to seem as though it’s coming from their staff, not just some random “System” name.
So, how do you get the value of your dollars spent on DocuSign AND ensure your customers get emails from their trusted reps, all while reducing or even eliminating any training material or time?
You work around what DocuSign provides!
We like using DocuSign PowerForms for these scenarios, but not just in the way DocuSign designed it. DocuSign PowerForms are web addresses that you can generate to associate with a Template you’ve created. The “Power” in PowerForms is the ability to use a standard web form to collect data and then send it to DocuSign via the web address to populate that form and send it out for signing. There’s no need for anyone to log into DocuSign to send out the form or to do a double entry of the data in your CRM / Intranet, then DocuSign.
So, what’s the catch?
PowerForms are associated with a single “Owner”. That means, the emails sent to your customers will always seem to come from the same person. May be that works for you, but for most of our customers, they want to not only have the email appear to come from their staff, they also want that person notified once the documents are all signed.
How do you get around this?
Well, you can write a fully custom integration and have your solution-cost jump by at least 10 to 100 times!
I assume you don’t like that idea.
Assuming you have a handful of Templates (different types of forms) that don’t change very often, and that you have a manageable number of staff for whom you’ve paid to use DocuSign, you can create the same form as a Template and PowerForm owned by each of your staff members as a user in DocuSign.
That means each of the PowerForms has a separate web address and, based on who has logged into your Intranet, the page can decide which PowerForm to pass the data into. In other words, you can setup a simple Intranet web page where your staff already logs in, where they’ll enter the data for each customer, may be even have it populate your backend database or CRM, then pass it into each rep’s custom web address (DocuSign form) to send out for signing.
This adds a bit of logic and very light programming on your Intranet, but you’re likely already tracking that information there and now just have to pass it into DocuSign.
All of this, without a single view of DocuSign Sending web app…and without expending any training time or dollars.
That’s it.
If you want to learn more about the details of how to do this, hit up one of our staff to give you the full breakdown!
Happy automating!
DocuSign & Adobe Sign’s Calculated Fields are Good for Much More than Just Calculations
How do you build a simple tool to both allow custom pricing calculations and contract signing on an eSignature platform? You use the DocuSign Calculated Fields or the Adobe Sign Calculated Fields, of course!
That’s the straight use of these fields, but they also open up other uses / options on either platform.
How are Calculated Fields Typically Used
A good simple use case example of calculated fields came up in one of our recent solutions where our customer wanted to allow their clients to get immediate pricing as part of an office cleaning and janitorial service quoting/contract signing solution.
The client would initiate the request directly on our customer’s site by selecting the types of services they needed, fill out their business / personal info and submit. The data is immediately sent to DocuSign and the web page redirected to that platform to review and sign the contract. The customer could change the square footage ranges from a dropdown list and, in the process, see an updated quote on pricing, all with different discounts being displayed for various sized spaces and different services. Once they signed, it was no longer a quote, but a new contract. Voila!
This is what’s often referred to as a Configure Price Quote (CPQ) solution, albeit this is a much simplified version of it.
None of that is new, though most folks are unaware of this cool control on the DocuSign and Adobe Sign platforms.
How are Calculated Fields Different
Calculated Fields on DocuSign provide the ability to dynamically conduct arithmetic calculations on data fields during an agreement signing. These calculations can be for numbers or dates, such as setting an effective date for a contract based on the date an agreement is signed. Adobe Sign additionally provides the ability to concatenate text to create suggestions of text or terms.
DocuSign’s Calculated Fields assume number calculations and, as a result, all data presented is right aligned. You can format the data to have 0 or 2 decimal places. Additionally, you can perform some data operations with predefined functions such as to obtain date differences.
Adobe Sign fields have more flexibility by allowing various date / number formatting and manipulations. As a result, you can manipulate data presentation for numbers and text, as well as the types of calculations that can be performed such as getting the minimum value from a set of fields, or rounding up/down of calculated value.
What are Some Unique Uses of Calculated Fields
So, you may be asking, “Ok, wise guy! What’s the not-so-typical use of calculated fields?”
Good question. I’m glad you asked! ?
Calculated Fields do very well in allowing your customers and document singers to dynamically change values to see immediate result during their signing, sure! In the process, the round-trips, requesting revisions based on specific customer needs, is reduced or eliminated, and your Time To Close or Time Value of Money metrics improve.
On the other hand, many integrated solutions and robust Contract Management System like Conga in conjunction with Salesforce, or custom applications, provide for uses cases that are simple to complex for presentation and even customer manipulation of the data before sending any of the information for signing to an eSignature platform.
Does that mean Calculated Fields have no use?
Actually, they have a hidden and an important value! Given the formatting options they provide, especially for numbered values, where it’s imperative the data is right aligned or localized (such as with date presentation differences between US vs. Europe or South America), they are a perfect solution.
All calculations and CPQ manipulations by sales staff or even customers can still be conducted on a system better designed for that purpose, then properly presented for final execution on the eSign platform.
Bottom line is that whether you wish to use Adobe Sign or DocuSign’s Calculated Fields to allow your customers to manipulate their custom quotes directly on those platforms, or you wish to incorporate at least the formatting of these fields in conjunction with your existing CPQ or other quoting applications, Calculated Fields deserve a serious consideration for data manipulations on your eSignature platform of choice.
Happy calculating!
In the world of banking and wealth management, it’s imperative to conduct a DocuSigning (electronic signing via DocuSign) face-to-face. This is a common pattern in this space where Bank Associates or Financial Advisors aim to provide white-glove service in the process of closing loans or opening new accounts. It’s also a point of confusion given the misleading DocuSign terminology of “In-Person” signing roles.
So, how do you accomplish this using the DocuSign platform?
Use Case and Solution Overview
Let’s first describe the typical use case. Bob, the owner of famous men’s clothing Bobby LaSuit clothier, has been looking to purchase a new facility to expand his clothing line production. He has already determined the total loan amount he needs, spoken with his banker, Vidya, and provided her with all the necessary information to complete an application, including his financials for the past three years, list of his assets and a pro-forma, demonstrating what growth he expects over the next 3 years and why needs to purchase the larger facility.
Vidya has entered all data into the bank’s Loan Origination System (LOS) and completed her due diligence. She is now ready to go over the final paperwork with Bob and get a signature to start the funding process. Both Bob and Vidya are quite focused on maintaining their relationship as they’ve been working together for some time, the result of which has been support from the bank for Bob from his startup days through various stages of growth.
So, on a Tuesday morning, Bob walks into his local bank branch to meet with Vidya and sign the paperwork. She sits across the table from Bob and reviews the documents with him. All seems to be in order. She then kicks off the DocuSigning process through a press of a button in her LOS. She captures an electronic signature and the system routes all documents to her and for funding.
DocuSign provides a couple of different recipient role designations that could address this scenario. Each of these roles have their intended use and consequences. The first option could be to use the DocuSign In-Person signing role. This is a fast way of getting to a solution, but a clunky method of accomplishing it as it creates a poor experience for the face-to-face interaction we have in mind. Alternately, you can embed the DocuSigning process in a custom-built application, such as the LOS in our scenario, which provides a much better user experience but requires software development efforts. Let’s review each solution further.
In-Person Signer Role
So, what is an In-Person signer role in DocuSign and what’s its intended use?
An In-Person signer role is one of the many DocuSign recipient roles that’s available both via API and the Web App interface. It can be used when both the person collecting signature and the signer are at the same physical location. So far, so good in fitting our use case.
In fact, this is the ideal setup for realtors and why DocuSign originally came up with the role. Why? Often times, realtors have assistants who may prepare paperwork for buyers in making offers for a new home purchase. The realtor, then, would visit the buyer to answer any final questions, go over the paperwork and get the signature. However, both the realtor and the realtor’s assistant just use the DocuSign Web App. What’s more, since the assistant is setting up the paperwork, he would want to notify the realtor when the paperwork is ready.
In this scenario, the assistant prepares the documents in a DocuSign Envelope via the DocuSign Web App and setup the Buyer as an In-Person signer, with the realtor as the Host. The DocuSign system, then, sends an email to the realtor as the Host. When the realtor meets with the Buyer, she brings up her email, finds the notification from DocuSign, follows the link which launches DocuSign and provides a prompt for the realtor to pass her phone, tablet or notebook computer to the Buyer to start signing.
You can read about the mechanics of how to setup an In-Person Signing on DocuSign’s Support Center.
They key here is that the realtor had to initiate the signing, and is required to be a Sender in the DocuSign system. In other words, there’s no direct way for the Buyer to start the signing. In fact, even if the Buyer wanted to sign the documents directly, he would have no way of getting to them unless the Realtor was present and able to kick off the signing.
DocuSign even provides a mobile app that helps the realtor kickoff the signing, but it still requires the realtor to start the process as the host. If you’re using nothing but the DocuSign Web App to collect data and signatures, this can be an ideal and quick solution. In fact, all that’s needed is the ability to create an initial set of DocuSign Templates to mark up where data needs to be collected from the Buyer, in this case, or other recipients and where they need to sign.
However, in our use case, Vidya is using a Loan Origination System to collect all data, track progress on the loan and generate the loan documents. To use the In-Person signing, she would then have to switch from the LOS to DocuSign to setup the In-person signing.
Assuming a DocuSign Template is used, this process leads to a poor user experience, with Vidya having to use up to three different applications to collect data, generate the loan documents, then kickoff the DocuSigning: she would collect data and generate the documents in the LOS, then save out the documents on her local desktop, log into DocuSign and import the document to apply a template and send for in-person signing, then either use the Web App or her email to kickoff the signing. All of these steps are manual that act as speed-bumps in completing the transaction. Such user experience often means Vidya and her coworkers will reject the solution, even if it helps reduce paperwork!
However, this is a very fast method of starting to use DocuSign to collect signatures and a good interim solution until a more robust method is put in place. It certainly reduces the use of paper, even if it doesn’t reduce the complexity of the transaction.
Embedded Signing
But wait! There may be a better method.
DocuSign also provides the means of embedding the complete signing experience inside another application. This is ONLY available via API (programmatically) and cannot be initiated via the DocuSign Web App.
The experience is quite unique. In our use case of Bob and Vidya, Vidya would continue to collect all data and run through her loan origination process in her bank’s LOS. When the time comes to kickoff the DocuSigning, she would simply press a button inside her LOS to the effect of “Start DocuSigning”. The LOS, in the background, generates the document as it normally would, but sends it programmatically to DocuSign to create a new transaction, what DocuSign refers to as an Envelope, and start the DocuSigning.
The programmatic call to DocuSign would also include details about Bob, including his name and email, as well as any security measures required to validate that it’s in fact Bob DeSuit who’s signing the document. Additionally, the LOS could indicate to DocuSign if there are any areas in the documents where Bob needs to sign or initial, as well as any remaining data that needs to be collected or just validated.
As all of this occurs in the background, Vidya immediately walks Bob over to a banking kiosk where she instructs Bob to enter his Business ATM Card, enter his PIN and choose to DocuSign his loan. The Kiosk would pull up the DocuSign envelope and allow Bob to complete the DocuSigning directly on the touch-screen. At the end of the signing, all documents are properly routed to Vidya and for funding. The LOS is also notified of any changes Bob made during the process.
This solution provides an added flexibility that’s not available for the In-Person signer role. Namely, if Bob gets a call, prompting him to leave the bank without signing, Vidya could initiate a change in the LOS to send an email notification to Bob’s business email so that he can complete the signing remotely.
Not only is this solution more sophisticated and robust, it’s also more user friendly. There aren’t any clunky steps that require manual intervention by Vidya. All routing of data to DocuSign to start the signing, the process of switching from a Face-to-Face to a remote email-based signing, when necessary, the notifications to all system and people after signing is fully automated. As a result, not only is the signing completed more often and in less time, the solution has a significantly higher chance of adoption within all branches of the bank.
In the end, the bank loan officers use the system more, the customer’s are satisfied that they don’t need to deal with printed documents, the bank saves on printed paper, and the overall solution ROI significantly improves as time-to-cash (funding of the loan and collecting interest) significantly increases. It’s not uncommon to see a reduction in time-to-cash or time-to-close for 75% of transaction from 7 days down to one hour.
So, which choice fits your needs best?