Business Process Transformation in Commercial Lending

October 18, 2018

Fulton Financial Corporation, a financial services company headquartered in Lancaster, PA, decided to invest in their commercial lending line of business and eliminate manual processes, streamline interdepartmental communication, and give lenders more time to do what they do best — engage with prospects and customers and solve business issues. The entire commercial loan origination process, a source of frustration for Fulton’s lenders, was to be transformed into an end-to-end enterprise solution with goals to

  • Improve customer experience
  • Improve employee experience
  • Reinforce effective risk and controls
  • Increase operating efficiency

The challenge? Getting a diverse group of stakeholders, with their own priorities and pain points, to agree and compromise on an enterprise solution that would adhere to a realistic scope and timeline. Systems Flow stepped in with an answer.

Scope Definition and Project Planning

Our first step was to support Fulton executive leadership in initial scoping and project definition efforts. Diligent on-site discussions resulted in an approach that would maintain sufficient rigor and also work within time constraints mandated by the bank’s board of directors. The accelerated schedule needed to accomplish

  • facilitation of large stakeholder workshops to inform current and future-state processes and architecture
  • follow-on workshops to capture and refine business requirements
  • strong IT engagement in creation of detailed solution architecture and interface control documentation

The end goal was to give business users a voice in a technical solution that included a commercial off-the-shelf solution (COTS) and potential custom solutions to supplement out-of-the-box functionality.

With mutual agreement on an approved project approach, we began planning the stakeholder workshops.

Capturing the Current State

All-day, multi-week workshops provided numerous opportunities to walk through the current commercial loan origination process, learn about pain points, and build a mindset of cross-departmental cooperation – a crucial factor in the success of this enterprise solution. Systems Flow ensured the workshops ran smoothly day after day, from room setup and breakdown to effective conversation, time management, and decision-making. Participant feedback was overwhelmingly positive – energizing the team to move on to future-state definition.

Envisioning a Future State

With the current-state process sufficiently documented with system context diagrams and activity diagrams, the team turned to designing the ideal future-state process. To understand the various desires and improvement needs, listening sessions were arranged with dozens of stakeholders spread across the commercial lending line of business.

Systems Flow was an integral partner in planning and scheduling, working closely with project leadership to tailor session cadence to expectations and obtain maximum project benefit. Whether a large on-site discussion or a small web-based teleconference, we ensured efficient use of everyone’s time and provided management with visibility into team resource capacity.

Weeks were spent documenting desired business process improvements, resulting in a comprehensive Future-State End-to-End Process, that included future-state system context diagrams, activity diagrams, and process narratives. The resulting process document contained the overarching vision for the project’s end-state and informed the business requirements gathering process.

Defining Business Requirements

Thanks to current- and future-state process definition efforts, we began the crucial business requirements phase with a clear understanding of the current process and its improvement goals. Over several months of on-site, day-long workshops, we crafted use cases and gathered business requirements from stakeholders of all major functional areas of the commercial loan origination process. Requirements were drafted and refined through several working sessions until five comprehensive Business Requirements Documents (BRDs) were ready for final review and approval. These BRDs included

  • Master BRD for overarching, cross-process requirements
  • Lending Processes BRD for commercial loan origination, modification, and renewal requirements
  • Portfolio Management BRD for requirements related to ongoing loan account monitoring
  • Generate Documents BRD to cover standard loan document, letter, and form generation requirements
  • Reporting and Data Analysis BRD to cover requirements related to transactional reporting and data analysis

Supplementary artifacts to the BRDs included

  • Data Matrix of data elements as identified by business users throughout the requirements gathering process; these data elements were intended to serve as data requirements for the chosen solution
  • Task Matrix of various auto-generated task reminders required by business users to complete necessary activities and satisfy compliance and policy mandates
  • Notification Matrix of auto-generated alerts needed by business users for task and loan origination lifecycle monitoring
  • Document Mapping templates for standard loan documents generated by the solution based on data elements within the solution

With this comprehensive set of documents, business leaders confidently moved into the vendor selection phase able to determine if a commercial offering aligned with their 1800+ business requirements. In addition, business and technical leads had a better understanding of the technology market’s “out-of-the-box” functionality and where customization or alternative processes might be needed to meet their business requirements. With this crucial understanding of business need, project management chose a commercial lending solution and proceeded to the next phase of the project: Design and Implementation.

Designing a Technical Solution

Having been involved in this commercial loan origination project since its earliest stage, Systems Flow was well-positioned to bridge the gap between the business and its implementation partner, ensuring technical reality aligned with business need. This technology-business alignment included integration specifications for 13 business systems that had to work with the commercial lending solution. These systems ranged from externally-hosted industry-standard services to locally-hosted enterprise software solutions. To identify all integration points and processes, we researched APIs and coordinated with system administrators, contract owners, external software vendors, and technical personnel. The resulting interface control documents included

  • detailed technical requirements
  • logical diagrams and physical diagrams of technology components and communication methods in the interfaces
  • data context diagrams and data models to illustrate data structures and data flows
  • activity diagrams to describe technical processing steps initiated by interface operations
  • notional data mapping based on business-identified data elements and data elements exposed by interfacing system APIs

To further assist in the integration analysis, we provided options analyses to business and technical stakeholders, to inform their decisions on final system integrations. For example,

  • Engage a development partner to create a custom interface with an existing legacy system? Or utilize the new commercial platform’s integration with a different third party application?
  • Pass system communication through a single enterprise service bus or integration platform as a service (iPaas)? Or develop point-to-point integrations?

Analysis of each alternative was based on the solid technical expertise of our solution architects coupled with a deep understanding of the business requirements. With our facilitation of options analysis discussions, the Fulton team quickly came to consensus and allocated resources accordingly.

In parallel with the integration design, we partnered with Fulton’s IT stakeholders in development of a solution design. Using solution architecture best practices and multiple facets of Fulton’s IT governance guidelines, a technical design was created using system context, logical, physical, and data context diagrams. In addition, our design

  • identified technical and procedural risks to the solution, based on design decisions
  • quantified expected user and data volumes
  • described high-level disaster recovery requirements (Recovery Time Objective/Recovery Point Objective)
  • documented IT stakeholder support responsibilities
  • provided an overview of the solution’s scalability options
  • documented open issues and design decisions

The solution design was a critical deliverable meant to not only memorialize the design decisions for audit purposes, but also empower the Fulton team in their solution implementation.

Ensuring Successful Transformation

Our on-time delivery of high-quality artifacts, planning, and facilitation was crucial to presenting a clear understanding of Fulton’s business need and keeping the enterprise project on track, especially with its highly visible schedule constraints. Our approach to business analysis and solution architecture along with experienced workshop facilitation brought everyone together effectively and efficiently, resulting in mutual recognition, decision-making, and a clear path to implementing a successful enterprise loan processing solution.

You, too, can achieve visible value and sustainable results.
Systems Flow can help.
Strategic thinking. Put into action.



The Time Dimension in Enterprise Architecture Diagrams

September 4, 2018

Including the time dimension in Enterprise Architecture models enables the modeler to depict the interaction of the events, tasks, and actors depicted in the model in a way that indicates the order of the interactions. There are many diagrams or modeling options to chose from to illustrate timing of events within a system or process.

A few favorites that are helpful in capturing the dynamic artifact-time relationship are:

  • Event Sequence Diagrams
  • Collaboration Diagrams
  • Activity Diagrams

Let’s look at how to capture time in event sequence diagrams. But first, we need to make sure we know the difference between 2-D and 3-D diagrams.

2-D versus 3-D Diagrams

Event sequence diagrams, collaboration diagrams, and activity diagrams stand in contrast to static diagrams such as the system context diagram.

In a previous article, we created use case examples for a fictitious company called ABC Corp. ABC Corp provides services to a customer who needs to log into a system and provide personal information to complete their customer profile. For the customer to successfully log in, a system administrator must provide login credentials by logging in and manually provisioning the customer.

To expand on this example, assume that there is also a customer service rep who logs into the system to provide services to customers. To represent this diagrammatically, we have several options depending on the goal. As mentioned above, if we wanted to depict a time perspective, then a system context diagram will not work.


As you can see, a system context diagram is two-dimensional; it shows the system artifacts and relationships of the artifacts to the system but makes no reference to the timing of events.

Show Time with Event Sequence Diagrams

Adding a time dimension to diagrams allows for a three-dimensional view of a model. However this does not mean you are adding hours and minutes, but rather you are adding a sequence to the activities.

Let’s take the ABC Corp example. In this example, we can show how rendering services is represented when a time sequence is added to a diagram. To illustrate, we will use the event sequence diagram.  Since event sequence diagrams are typically done from one user perspective at a time, we will start with the system admin. In the sample event sequence diagram below, you can see the sequential execution of each activity as the system admin interacts with the system. Each step in the process flow is accounted for and its occurrence within the sequence is known.

Similarly, for the customer, the event sequence diagram would look something like this:

Let’s explore the last perspective of the customer service rep.

In comparison to the system context diagram, the event sequence diagram clearly shows when each step in a process occurs and when and why each user is interacting with the system.

Event Sequence Diagram Considerations

One drawback to consider when representing time in a diagram is that a single diagram will, for the most part, contend with the viewpoint of a single actor/stakeholder. Even though it does not show when activities are supposed to take place, the system context diagram has all actors and all possible activities performed on the system on one diagram, whereas the event sequence diagram has to be done from each individual actor’s perspective in order to be effective.



A Technology Roadmap for Regis College

August 18, 2018

When Regis College, a private university in greater Boston, sought to create a technology plan to support their performance goals, they turned to Systems Flow.

Like many higher education institutions, Regis was grappling with a series of questions regarding the ability of its technology environment to manage data and information flow. How well was data being shared, if at all, between admissions, student services, and alumni relations? Was the school’s procurement system meeting the needs of its stakeholders? And, which of these challenges should Regis address first?

By listening to and mapping the needs of multiple stakeholders across the campus, we helped Regis identify gaps and align technology solutions to business goals.

Identifying Business Drivers for Technology Decisions

First, it was crucial to understand, document, and socialize the key business goals and challenges surrounding the college’s technology infrastructure. We actively elicited business strategy from groups representing every business function at the college to identify key business drivers that inform IT investment decisions. Our analysis outlined challenges and recommendations, and identified several immediate solutions to ongoing technology problems.

Making an Informed Technology Investment

The culmination of our analysis of Regis’ business strategy and current-state technology environment was a 5-year Technology Roadmap. This plan detailed recommended technology approaches to realize institutional strategic objectives, and:

  • provided a complete view of Regis’ current technology architecture, including metrics on users and hosting disposition (cloud or on-premise)
  • identified relationships between business challenges and IT challenges
  • analyzed trends in the technology application landscape
  • identified gaps in automation capabilities, information management and business intelligence, ERP functions, and process, governance, and training
  • involved facilitation of several onsite elicitation worksessions, that not only settled long-standing disagreements on how data was defined, but also formulated a baseline for future data transformation
  • created an Enterprise Data Dictionary to better ensure cross-functional understanding and data consistency; defining over 150 business terms spread throughout multiple disparate databases across the institution
  • proposed actionable recommendations and a roadmap to achieve them

“What Systems Flow produced was a succinct and actionable set of recommendations that, when realized over the next 3-5 years, will ensure that technology is a valuable contributor to reaching our strategic goals,” said Kate Korzendorfer, Regis CIO.

With this business-aligned technology roadmap in hand, Regis College is able to strategically focus its technology investments in areas such as data intelligence and information management, student engagement through mobile technology, process automation, and lean IT process and governance.

You, too, can achieve visible value and sustainable results.
Systems Flow can help.
Strategic thinking. Put into action.



Technology Adoption Strategies for Business Systems

August 7, 2018

Regardless of an enterprise’s size and industry, technology touches every aspect of a business’s operations now more than ever. Successful technology implementations have always been important but in today’s economic landscape, technology implementations NEED to be successful as they can make or break a business.

Here are some horrific examples of what happens when technology implementations fail:

The implications are not just lost revenue but lost jobs. Take Target Canada’s example; over 10,000 jobs were lost when their SAP implementation encountered problems. Most of these failures are a result of a myriad of reasons that include poor project planning and insufficient technical knowledge. However, one reason that’s almost overlooked but is a significant contributor, especially during the post go-live phase, is user adoption. Users expect a seamless experience that allows them to accomplish their deliverables with ease and efficiency. Technology implementations that provide this tend to be very successful.

Common Technology Adoption Misconceptions

Before we dive deeper into understanding adoption strategies. Let’s explore some misconceptions when it comes to users’ adoption technology.

Adoption is not all about digital transformation There is a misconception that adoption is about embracing a new technology as a result of some digital transformation effort. Adoption can also be about the new and existing processes or, more simply, it can be about the efficient and full uses of technology already implemented.

Adoption efforts start post go-live In a case where adoption concerns a new technology implementation, the usual tendency is to emphasize adoption in training related activities post go-live. In fact, adoption efforts should start when requirements are being collected and the solution design is being drafted. It starts by making sure there is buy-in from end users from the beginning and throughout the process, especially before blueprinting. If this does not happen, buy-in will be much more difficult later in the project. Even worse, a solution that users do not want or cannot use will be implemented and adoption will be near impossible. This is probably a major reason why some companies’ implementations are scrapped and millions of dollars wasted. ZDnet.com estimated in 2012 that globally, companies lose $3 trillion because of failed IT; which is a combination of IT projects that add zero value to users, failed capital projects, unplanned activities, and rework.

Adoption is all about users While the focus of adoption efforts is on the end user, and rightfully so, executive sponsorship is important as well. Even if senior management does not use the technology in question, their visible and active support of the technology will inspire their subordinates to use it. Sponsors must remain visible throughout the lifecycle of the project. A side note on this is that executive sponsorship is not only helpful for adoption but the visibility of sponsors inspires the tracking of the benefits of a technology implementation to continue throughout the project lifecycle and not just simply during the first months of the new car smell.

Adoption Strategy Considerations

When discussing adoption strategies, there are a few things to consider:

  • Training
  • End-user Buy-in
  • Managing Expectations
  • Managing Complexity
  • Governance
  • Effective Communication
  • Executive Sponsorship

Training

Training is as important as the end users. Often, Change Managers will focus on training end users on using the newly implemented technology with the belief that once users are trained, they will start using the technology automatically. This is not always the case. Most training is quite generic, technical, and at times unrelatable by the users. Instead, Change Managers should make it a point to utilize user-specific workflows with a before and after type of approach, preferably focusing on how the pain points were addressed in the new implementation. In addition, Change Managers should pay close attention to the learning curve of the users. If the technology being implemented is complex, multiple training sessions may be required so enough time should be allocated to account for such a scenario.

End User Buy-In

We discussed this above but there are still a few things left to say. End users know how the business works and probably have built processes to cope with the inefficiencies of the technology they use. If a process has proved to be useful, users will develop a habit to default to it. At times this results in users circumventing the implemented technology which means all the work and money put into implementing the technology goes to waste. If you are in charge of such a project, grab a calculator and start heavily discounting your ROI estimates (assuming you were tracking ROI in the first place). Below are some key points to consider when addressing user buy-in concerns:

  • The longer a technology/process has been in use, the more effort is needed to convince end users of the value of new technology. This is simply because humans are creatures of habit. After getting used to a process, it becomes quite difficult to change. As a result, Project Managers should allocate enough time to get all users on board. I will also reiterate my point above that there should be extra effort to demonstrate benefits during the planning stage. However, be careful to manage expectations.
  • Adoption may be about fully utilizing an existing technology or process. In this case, it is important to highlight to end users the use of best practices and importance of the improvement of efficiency metrics. The idea here is to emphasize value and be able to present it to the users.

Managing Expectations

Sometimes adoption issues within an organization are a matter of unmet expectations or at times “miscommunicated capability” of the technology. At times, businesses are pushed to change a technology because it is no longer keeping up with the business operations and is causing a headache for end users. This is a good scenario during the planning process because the end users will be the easiest stakeholders to convince about a transformation. However, they also could be a difficult bunch post go-live because the technology implemented did not deliver on their expectations. They may have been promised a sports car but instead, a tractor was delivered. The tractor will still get from point A to point B but just not as fast as expected. At this point, Change Managers sort of have a mutiny on their hands. When such situations are not managed well, entire implementations can get scrapped. You can browse the web and find tons of scenarios showing what type of carnage is left when this happens. The key is to keep realistic expectations for end users and to detail out what changes to expect while making sure to keep them informed along the way.

Managing Complexity

Quite often complexity is confused with complicated. As Theodore Kinni notes in his MIT Sloan Management Review article, “Complexity involves too many unknowns and too many interrelated factors to reduce to rules and processes”. On the other, complicated may mean hard to solve but solvable or resolvable with systems and processes. An interesting note made by Kinni is that solutions to complicated problems do not always work on complex systems. If left unchecked, what ends up happening is the implementation of a technology with potentially too many features and requirements that very few users want with the majority left figuring out how the technology fits into their workflow. Dealing with complexity can be difficult. Below are some suggestions on how to address complexity in order to increase user adoption:

  • Identify complexity first, distinguish what is complicated and what is complex. A good rule of thumb is to look at your organization, processes, policy etc. and, if you can distill them into logical rules that can be converted into systems or process you have a complicated scenario. If you seem to have difficulty figuring out if any set of activities is a process and things seem disjointed, you likely have a complex scenario. Refer to Kinni’s article for ideas about managing complex business scenarios
  • Simplify as much as you can. A starting point would be to determine the business objectives. Next, determine all the processes that are critical to meeting those objections.  Then find common interconnections between the processes. You can then try to cluster these processes based on the interconnections and start determining which ones are critical, which ones can be consolidated, or if new ones may need to be created. By doing this you are able to make sure that any part of a business can be reduced to rules and processes that drive business objectives.

Governance

Governance is key to ensuring the users and the business as a whole are adhering to set rules and laws. It not only avoids legal issues but at times is helpful to ensure a good service or product is provided to customers. At times the adoption of technology is affected when rules, policy and laws are not so clear to the user.  For instance, users will bypass a system if it does not provide a direct route to achieving their task. They would rather opt to perform the task outside of the system with less hassle. The system’s utilization will gradually decrease over time and therefore its adoption as well. A good approach to trying to solve this would be to bake in as much of the governance into the technology as possible. At times this may be difficult especially where there are numerous variations to process. In this case, the exceptions should be clear, documented and easily accessed for reference.

Effective Communication

Sometimes adoption is a matter of awareness. Users need to be aware of the progress of a project when a technology that affects them is being implemented. Most importantly, users need to know how this technology will affect them. Users should feel included in the entire process; that way the changes and the technology implemented are relatable, thus lowering the resistance to adoption. Below are a few pointers on ideal communication that can help increase user adoption:

  • Involve power users in all phases of the project (these are your adoption champions and can help sell the benefits  to other users)
  • Send regular bulletins to all affected users.
  • When sending out bulletins, make sure to incorporate relatable terms and figures. For instance, mentioning of major pain points and how the new or improved technology will resolve them can create anticipation which will likely help increase adoption during the first few months post go-live.
  • Engage users through pulse checks post go live. This can be achieved through surveys of the user’s opinions. The responses can be published but should be anonymized.
  • Share the metrics on the project performance, including ROI metrics post go-live. Usually, these metrics are reserved for the steering committee and managers, however, they are helpful for end users to be able to measure the effectiveness of the implementation as well as their contribution to it.

Executive Sponsorship

Users are likely to be receptive to ideas and suggestions put forth by their executive leadership. If the leadership endorses the technology as well as champions its use, then the rest of the rank and file will likely be more receptive and ultimately less resistant to adoption.

Summary

Even though all of these points may seem to be effective separately, they should be considered in unison. Focusing only on one is not enough. Adoption is, in large part, an emotional business and you need as many tools in your arsenal to engage users and drive adoption.



« Previous PageNext Page »