The Road to Digital

All enterprises continuously strive to trim their bottom line through operational efficiencies and grow their top line by enhancing customer experiences and discovering new revenue streams. An appreciation for how the Digital Economy functions is key in accomplishing this for the new age enterprise. In doing so, many challenges and opportunities present themselves. As always, decision-makers look for clarity in terms of what potential benefits can be realized and when. There is also a need to understand (and plan for) impacts to various stakeholders including employees, customers, vendors/other business partners. This article explores these aspects and some thoughts on what elements that could be part of an organization’s Digital Strategy and a roadmap to executing on the strategy.

Digitization & Digitalization

A key aspect of this is the difference between digitization and digitalization. Others have written about this and there are many definitions that have been proposed in the recent past. Hopefully, some examples from our daily routines can help clarify this distinction.

Until recently, most professionals had a habit of keeping a record of meetings and events in a physical(paper) calendar/diary. Sometimes, maintaining separate diaries for personal life, social commitments, and official meetings. When software tools like Outlook/Google calendars became more ubiquitous, the calendars were digitized. Once the data is available in digital format, some of the advantages become apparent – for example, having a better understanding of one’s availability as schedules from multiple digitized calendars are digitally superimposed. We can also create more digital experiences like finding the earliest time when multiple parties can meet based on availability as published in their digital calendars.

This simple example hopefully illustrates the difference between digitizing and being digital. Digitization is the process of converting data that exists in a physical form into a stream of bytes. Being digital is the ability to use that digitized data to gather information that is useful in performing higher order activities and redefine processes to make things better. This data is typically consumed in tools from analytics, artificial intelligence, process modeling and the like.

Let’s look at a specific illustration from the restaurant industry where these concepts apply. The typical workflow when we visit an establishment. This thread on yahoo answers details the workflow behind the order/ticket system for a typical customer. An abridged version: a) Someone jots down food orders. b) Order queued up for preparation by the kitchen staff C) Food order prepared by kitchen staff. d) Food is served to the customer. e) Customer pays the bill. There could be variations, for example, in a fast food establishment, we pay at the time of ordering.

Now, this system can be digitized by recording orders using a software system. Digitizing the order allows us to be more efficient at some things. If the goal is to provide faster service to our customers, it may be possible to tweak the systems/workflows to achieve this. However, we should know what to tweak. Are customers waiting a long time to place their orders or are they waiting longer to get their food once their order is placed? Does the answer change by time of day? Once we know the answers to these questions, the solutions may be more apparent. If customers are having to wait to place the order or if food is taking longer to reach their tables after it is prepared, then we can look at a different set of solutions. Options may include increasing the front office staff or taking the digitization closer to the edge. Like we see in many eateries at airports, customers seat themselves and order food from a device on their table or from their phones. On the other hand, if the bottleneck is in the kitchen, we need more staff/automation in the backend. Some establishments allow customers to self service themselves partially as they serve their own soda from a dispenser. We can analyze data from the first wave of digitization to understand the problem better before rushing into a solution. This process of using analytics to understand the bottlenecks, what to optimize and tweaking workflows is being digital.

From the above scenario, one can perceive how digitization is a prerequisite for digitalization. Digitization becomes an operational necessity. Typically, this step involves higher investment and requires the blessing of executive management. Once an enterprise is digitized, folks on the ground would feel empowered to create efficiencies. Analytics will help them move forward with solutions to optimize based on evidence as opposed to just intuition. Solutions are implemented with greater confidence thereby reducing risk.

Summary

Digitization is the process of creating a digital representation in bits and bytes of data that is present in a physical form such as on paper, documents and pictures. Digitalization is the logical next step; using the transformed data to create efficiencies through alternate operating models. This will increase customer delight and perhaps even create new business models.

In subsequent posts, I will share some thoughts on how technology enables organizations to be more digital; changes in the operating model will help accelerate this process; ways in which we can use technology to reimagine how work gets done; how this impacts the people in the ecosystem; how the nature of their work itself may change and changes in attitude that will help employees be successful in this new environment. I’ll try to illustrate some ideas drawing from different industry segments.

The Road to Digital – Part II

In my earlier article, we discussed how investments in digitization set up an organization to reap the benefits of being in a digital world. In this article, we will explore some of the technology trends and tools that make such digital journeys possible using an illustration from financial services. We will use a scenario of opening an account at a typical bank to trace their digital journey.

Context

The figure below shows a typical sequence of events that banks use as part of the Know Your Customer (KYC) to onboard a customer. Let us trace the digital journey of this fictitious bank in realizing this use case.

These were the sequence of steps that the bank will follow to open an account.

Initiation

• Potential customers used to fill a multiple page application form on paper and hand it over along with copies of documents like a passport/Driver’s license/incorporation documents to a front office person.
• The bank employee would then enter the same information on an internal system.
• There could be some further communication with the customer when this information is verified. For example, if the address on the application does not match the address on the driver’s license, additional documents like a utility bill may be requested

Customer Due Diligence

• These details are then reviewed by employees from the compliance department as part of their due diligence. This is to ensure that the account complies with Anti Money Laundering (AML) laws and will not be used for other illegitimate purposes. They would scan the customer information across multiple databases to see if the individual is a Politically Exposed Person (PEP) or if the name exists in one of many sanctions lists maintained by OFAC (Office of Foreign Assets Control).
• During this process, the bank may seek additional documents from the customer depending on the individual circumstances – for example, if they discover that s/he has ties to a nation that is classified as high risk.
• Another bank employee then computes a risk rating for the customer using a spreadsheet. The spreadsheet contains information from the result of the scans, nature of client’s business, where s/he lives, what is their nationality, which countries are they likely to operate and other data they deem relevant.

Disposition

• For customers that are deemed to be low risk, the application is approved and sent to another department to open the account. For high-risk customers, a committee of senior officers will review the application to determine if they will approve the application or decline.
• The documents and details of the disposition are recorded and filed for safekeeping in case of an audit or further reviews.

This entire process needs to be repeated periodically in the event that circumstances that impact customer risk changes. The frequency of reviews varies depending on the risk rating the customer received. Also, this process could be more involved in case the client is a corporation as opposed to an individual. The due diligence phase will include steps to identify who trace the ownership and identify the ultimate beneficiaries. The bank will need to gather the information from each beneficiary and conduct individual risk assessments.

Challenge

Over time, the bank found that they were losing ground to the competition and initiated a study. They identified several key opportunities for improvement.

Poor customer experience

• Customers found the forms were not easy to fill. The same information was requested in multiple forms. They were not sure if some sections were applicable to their situation and if they need to fill it.
• There was some frustration when additional documents were sought after a few days. Customers wondered why the bank did not ask for it earlier.
• Customers were not sure how long the process will take and would have liked to track the progress of their application.
• This frustration was worse for some existing customers who wanted to open additional accounts when they realized that the bank is asking for information that it already has since it was provided to them earlier when opening the previous account.

Inefficiencies within the bank

• The bank was losing money as delays in account opening translated to delays in realizing revenue.
• An audit discovered that many of the reviews that needed to done were missed. This generated a huge backlog. It was difficult to predict when they will catch up with the renewals and what resources were required to do so.

Solution

Management decided to invest in a digital program that improves the client onboarding process. A small cross-functional team comprising of 4 developers and a representative from the client onboarding team was formed. They were asked to develop a Minimum Viable Product with the following features.

• Create a better user experience for the customer. Start with a simple online application that the customer can use to open an account. The forms were designed to be interactive so that responses to the initial set of questions would drive what further questions were asked.
• Most of the customers were spared the trouble of responding to questions that were deemed more intrusive unless it was absolutely necessary. For example, an entire section was required to be completed only for individuals from nations classified as high risk.
• The Client Onboarding team from operations worked with the technology team to model the entire workflow using a process modeling tool.
• The process model was developed using an intuitive visual interface that looked like a flowchart detailing the individual steps and decision points. From the model, many aspects of the workflow application were generated automatically. This meant that corrections could be made quickly and a simple portal was developed in weeks.

Initial Results

The first version was quickly tested in the cloud environment and piloted in a test region. The feedback was very positive. Customers were happy as they were able to apply and track the status of their application from the comfort of their homes. The self-service capabilities freed up the bank employees to catch up on the large backlog of renewals. Executives at the bank were also able to see on a real-time dashboard the status of applications in flight and how many applications were in which state in the workflow. Knowing the choke points allowed them to redeploy staff to areas where they can make the maximum impact.

Next Steps

While the initial pilot was successful, there was obviously a lot of scope for improvement. A backlog of additional work was created. Below is a sample of some of these features.

• Expand the pilot to other regions the bank operates in.
• Use a Document Management System to store customer documents and tag them. When an existing customer wants to open a new account, we can use the same set of documents without troubling the customer. The KYC steps have to be repeated as the new account could be requested with a different set of attributes that may change the risk rating.
• Use an OCR on the documents to prepopulate some of the data the customer or operations staff enters. This saves time and eases the burden on verification as the data is taken directly from the document.
• When documents like passport/license expire, automatically trigger notifications to the customer to provide current documentation.
• Explore opportunities to eliminate manual entry. For example, if there is a question regarding a customer’s employer or are of business, can we pull this information from social media sites using a RESTful interface? Customer can still edit the information if it is not accurate. Similarly, can we use APIs from third-party data providers to pull data that is useful for the risk assessment?
• Codify the rules for computing the risk rating and automate this process. This may not be possible in all scenarios. Special rules for arriving at the score may be applicable for specific regions. So we need the ability to automate some steps alone on a per-region basis while keeping other steps common across regions.
• Many other areas where region-specific customization may be required were identified. For example, In one country, an employee would perform all the risk assessment activities for a customer. In another region, people specialized and were organized by groups depending on the type of screening that was being done. Also, all the employees in this country would be co-located while in the other country, many employees operated from virtual offices in their homes.
• Integrate the workflow with staff calendars and skills database so that if someone is on leave, their work can be reassigned automatically to someone else with similar skills.
• Use presence/availability information from mobile devices or chat status to distribute the workload.
• Incorporate electronic signatures in the workflow where legally feasible
• Expand the online form to other channels like mobile devices and chatbot.

As we see, there are many opportunities where digital technologies can make an impact. The product owner on the team that represents the client onboarding team is working with the various stakeholders to understand which items in the backlog can create maximum impact; analytics can also help her identify bottlenecks in the process and volumes involved. She uses this information along with data from developers on the effort involved to prioritize which capabilities will be developed when.

Most of the technologies we discussed are quite mature and can be leveraged in organizations to make incremental improvements gradually. As organizations reach a point where they are continuously making small improvements, they can look consider introducing relatively more recent technologies, like AI and blockchain. AI initiatives are more successful when one starts with a significant amount of data collected over time. For example, during the Enhanced Due Diligence phase, AI may be able to make some of the decisions being made by the committee of senior officers. While the platform pushes work to employees based on attributes like skill, access, geography, and presence, AI can be used to spread the knowledge by pushing work to employees with the goal of spreading the expertise across a wider section of the staff. A junior employee may be assigned advanced tasks if the system determines that the junior employee can take help from experts in the same location and make use of available slack without impacting the end to end cycle time. In other use cases, smart contracts can be used to initiate additional workflows if certain conditions are met. One can imagine scenarios where an account is frozen or funds are automatically moved when triggered by an external event, say when the system detects a change in ultimate beneficial owners for an account.

Catalysts and Inhibitors

Many advances in technology make this story plausible. These include Cloud Computing to provision/release computing and storage resources at will; Mobile Computing and Unified communications for multi-channel access and to capture presence information; Analytics; Process Modeling tools; Document Management etc. More than any single technology, a successful digital journey exploits the combinations of these. It is the convergence of these technologies that make it impactful.

Having said that, capability in technology needs to be supplemented with the appropriate processes and people with the right mindset to achieve success. A key success factor is the ability to experiment and incorporate feedback loops in this journey. Start with an aspect to improve; implement a solution; check if it gave the desired results; then expand on the original idea/pivot.

Until recently, IT organizations were not equipped to support their businesses in this agile manner. It was too expensive and time-consuming. As these technologies evolved and tooling became more mature, the nature of development itself was changing. We will see how with more automation many tasks performed by IT personnel became redundant and most activities morphed into some form of development work. As a result, those who embraced this change benefitted more. Over time, there were fundamental changes to how work got done, statuses were published and results measured. The model-driven capabilities in software development are not restricted to just process orchestration and workflow, platforms like JHipster automatically generate database and code to store/manipulate data and deploy them as microservices into the cloud-based on a description of the domain elements. Other low code environments bring software development capabilities closer to the end-user.

The ability to make a large number of small releases at frequent intervals is key. Keeping a release very small to just one or two features allow us to make realize the value from that quickly. It also translates to reduced risk. Less feature means that it is less like for something to go wrong. Even if something does go wrong, since the magnitude of change is small, rollbacks will be easier. The use of technology has to be in lockstep with the appropriate development processes to make an impact. Developers can no longer rely on an army of manual testers if one needs to deliver at the cadence that is required. Instead, the tests themselves need to be automated. This is the only way in which one can confidently assert that we have not regressed after making a new release, (i.e) the features that were working in an earlier release continue to work. This approach to software engineering in which software functionalities are delivered frequently through automated deployments is called Continuous Deployment.

I recently came across this article by Gary Maier, where he highlights several anti-patterns we may unconsciously follow in our rush to embrace the latest technology trend. For example, just deploying an existing monolithic software on the cloud may not always yield the benefit we desire. It does lower the entry barrier; however for us to truly reap the benefits of the cloud, developers need to look at entire environments as a consumable as opposed to a durable commodity. Just like infrastructure can be provisioned/release at will; we should have the ability to stand up and tear down entire software environments whether it is for development, testing or production at a moments notice. This includes servers, code artifacts, configuration information, storage, databases, and static data.

Conclusion

We reviewed some of the catalysts for digital transformation against the backdrop of a typical fintech use case. We also saw how an agile approach to digital transformation has a better chance of being successful.

In the next post, we will further explore the cultural aspects of a digital transformation, some thoughts on organization structure and how various stakeholders may need to adapt for the digital age.

The Road to Digital – Part III (Execution)

Background

In earlier articles in this series, we explored these aspects from Digital Transformation

• Digitalization and the beneficial outcomes that one can expect by undertaking a journey in digital transformation.
• The catalysts in terms of advances in technology that enable digital transformation and a more concrete example of how such a journey would look in a typical enterprise.

In this final article in the series, we will explore how this impacts the people who participate in the journey; how employees need to reinvent themselves so that they continue to be valued; and how enterprises adjust their operating models to take advantage of these trends.

The KYC example in the previous post illustrates how agile methods are used in the software development process. However, agile is not just a software development methodology but applies as much or more to other aspects of the business. Let us stay with the KYC example in the previous to explore this further. The Product Owner for the program was not from the IT department, rather she was selected from the operations group responsible for performing KYC. She had a vision for the end product informed by an understanding of the goals of the program. She directs the communication efforts, alerting the team to significant events that impact the program such as a new regulation that requires capturing added information. She is also responsible for any course-correction that is inevitable in large engagements as we learn to use the feedback from earlier iterations. She does this by managing the backlog and prioritizing features as necessary. The prioritizing activity is a judgment made by her based on the following estimates.

• Value: Which feature when implemented has the greatest impact on the program. Being part of the business/operations group, she is better equipped to make these decisions rather than someone internal to IT.
• Development effort: The dev team provides her with an estimate of how easy/difficult it is to develop the capability for a feature.
• Other operational factors: These could include the effort to train staff if it entails a significant change from current procedures and communications that need to be sent out.

This shift in focus to a value-based operating model has implications for financial models for budgeting and accounting, organization culture, and talent management.

Organizational impacts

Financial Models: Budgeting vs Funding

Most enterprises have an annual budget cycle that looks something like this

• Somewhere around August, this exercise is kicked off. As the owner of your “cost center”, the manager is required to provide his “ask” in terms of the budget for the next year
• If lucky, he is notified in November/December, that the ask was granted with an x% reduction. The not so lucky ones get notified in January.
• In February, he finds out that he is “over budget”. The expenses from December were not properly accrued and the “Carry Over” projects have to be closed.
• In October, he is informed that he “under budget” and will scramble to use it lest he loses it

The manager’s performance is rated against his ability to stay within budget instead of the value delivered. This inhibits his ability to respond to changes in the operating environment. This misalignment has at least one of two consequences. Technology initiatives tend to deliver lower value or there is opaqueness around work performed.

Here is an alternative approach leveraging agile practices to make a distinction between granting money, viz., budgeting and managing money, viz., funding. Some elements of how such a mechanism might work.

• Budgets are allocated for specific themes in the annual budget under a broader, (say) three-year program.
• Product Owners map their themes or epics under the broad budget items.
• As the user stories within the product backlog are elaborated, the various components of cost are estimated by development and operational teams.
• Similarly, the expected value of implementing the story will be provided by the product owner. To do this, the product owner works with the user community for a feature enhancement/new capability. If it is to pay off technical debt, the decision will be made based on input from the technical team.
• As described before, the grooming and prioritization of the product backlog are informed by an assessment of both the cost and associated value.
• Post-deployment, the value redeemed within the budget cycle is captured.
• Additional funding is granted based on the value redeemed.
• Tools used to manage the product backlog are integrated with the financial tools and processes so that the requisite monitoring and alerting happens.
• Tool integrations also promote transparency in reporting as the underlying data from financial tools and product backlog are synchronized
• Quarterly/bi-annual reviews could be more productive. Decisions on whether to provide/deny additional funding are informed based on accurate information from the reporting tools.

Cultural

It is well understood that there is a strong correlation between the success of transformation initiatives, organizational culture, and ease of acquiring mindshare with the stakeholders. Let’s explore some strategies to overcome resistance and promoting the status quo. Many of us have encountered/experienced sentiments like this is the way things have always been done or why fix what’s not broke. Here’s a great experiment that illustrates this point. Let us take the same KYC example from the previous article. It is quite possible that employees in different geographies have allegiance to a process followed locally and so resist changes to standardize. Many of these employees may be “traveling in time” on a daily basis. At home, they and their family members frequently interact in social media; they use the latest smartphone; use apps for checklists, calendar, monitoring investments and interacting with various service providers. The same employees when they show up at work may get transported backward in time. They open 15 windows for emails, its attachments, multiple spreadsheets, and proprietary applications often copying data from one window to another. Influencing the employees who do not find this time travel all that appealing by showcasing how the same workflow can be reimagined using a prototype may be helpful.

A consequence of changes in how work gets done is refactoring of the workforce. Many of the advancements in technology also enable operations and other non-IT personnel to self-service themselves instead of relying on IT. With some training on tools like rules engine and tools to author process models, many of the SMEs can work on product/platform teams that manage the workflows. Conway’s law is a significant impediment. Here is one article that discusses strategies to overcome this.

Another consequence of the financial model suggested earlier is that there is more process, but less bureaucracy. Teams that focus on due diligence, governance, and administrative matters can be leaner, but also more effective.

In his book, Dealing with Darwin, Geoffrey Moore describes the idea of core vs context to describe how organizations evolve. A company’s core is what differentiates it from its competition. It is something that gives the company a unique advantage because of an IP or a secret sauce it holds and through which it generates higher revenue or can operate with a higher margin. Context is what the company does that is necessary for it to function, but not a differentiator in the marketplace. In this interview, Moore offers some suggestions for companies to discover their core. Data Science can also help. This is important for digital transformation initiatives when it comes to setting the agenda and prioritization. While determining ROI and where investments need to be made, organizations would prefer to invest in its core.

For example, in financial services, company A may have an established presence and a very high market share but be constrained in its ability to innovate quickly. Company B, a new fintech, on the other hand, could be very agile, quick to market new capabilities. They would likely have greater success in attracting new customers by highlighting a great user experience and less friction during the onboarding process. Company A, on the other hand, may choose to focus on customer retention strategies while it figures out how to disrupt from within in the background – like in the KYC example earlier. As an example, because company A has been around for longer and since it enjoys, greater market share, its ROI when it comes to investing in technologies like AI that leverage data science. As time progresses, company B may be acquired by company A – or company B may choose to reinvent itself. It may be able to offer the algorithms it developed using the large amount of data as a service to other FinTechs.

Another example would be a company that is expanding through mergers and acquisitions. An important goal might be to integrate the various systems in order to provide a unified experience to all parties. Such companies may choose to adopt an API first strategy to further these goals.

Impacts on people and their roles

The KYC illustration in the previous article highlighted the changes in how services are developed, delivered and consumed. For this to be successful, the individuals who develop and deliver these services need to not only develop different/additional skills but also undergo a change in mindset. Let us explore some these in this section.

Developer: In a traditional setting, there were distinct roles associated with requirements gathering, design, coding, testing, deployment, and support. Each of the roles became more important in the corresponding phase of the project. In a typical agile sprint, all these activities are performed within the sprint cycle. The shift toward making more frequent, but smaller releases means there is less opportunity for handoffs across teams. The same team code, test and deploy the software. In addition, they participate in backlog grooming sessions in lieu of traditional activities like requirements gathering, design, and estimation. With the advent of frameworks to support automated testing, the act of testing also involves coding and so the a full stack developer is expected to perform all these activities.

In terms of skill, this means s/he should know her way not just around the traditional development tools like an IDE, but also work with the product backlog and tools used in continuous integration and continuous delivery. Examples of these are Jira, Rally, Confluence, Jenkins, TeamCity, Upsource, git.

Further, it is not just knowledge of these tools, but also the mindset of not being more accountable for what you produce as opposed to throwing stuff “over the wall” to the testing team/documentation team. Working with an agile team can also be different. The team is the unit for which many of the performance metrics around productivity and quality are captured. So the dynamics within the team are different. There is an expectation to share all artifacts/work products even while they are still work in progress.

Project Managers: A project manager typically morphs into a scrum master role. Instead of managing, this person becomes more of a facilitator ensuring that the team follows a routine within each sprint and that removes any impediments that the team may face.

In a traditional project, a major activity for a PM would maintain checklists, add entries as new tasks are discovered and check them off when done by following up with the individuals. In an agile team, there is greater accountability with each developer and s/he is expected to update status directly in the backlog. The scrum master’s role is now elevated to that a process QA – Ensuring that team members feel empowered to perform their activities and removing any friction in the process.

A project manager who understands the business processes; amassed significant subject matter expertise and has nurtured relationships within a user community may also be effective as a product owner in that domain.

Product Owners: We have discussed this role at length. Someone who has the vision and maintains a roadmap for the product; understands the value proposition and makes informed choices on prioritization by weighing expected value against cost estimates. The typical roles and responsibilities of a product owner are well documented. Instead, we focus here on the aspects of this role that are critical from a digital transformation perspective.

The PO is responsible for marketing the product within its user community and other stakeholders and secures funding as necessary. They are in many ways change agents. Creating value also means driving value and promoting adoption. The PO has a good understanding of the organizational dynamics and navigates her way to driving value.

Similar changes should be expected within the support functions that are contextual to the enterprise.

Summary

We saw how organization can use digital trends to transform to reach their growth target and be more efficient. We reviewed some of the catalysts and inhibitors for enterprises starting on this journey. Finally, we also reviewed execution strategies that organizations may consider to implement such a program along the dimensions of people, process and technology.