by Charles Parat, Data Consulting Director
AGILE TRANSFORMATION:
Accompanying and supporting your company’s data-driven transformation by continuously providing new business values
In the previous chapters, we reviewed what it takes to serve the business needs of an organization based on the virtuous use of useful data:
• understand the business challenges and identify the data that matter to drive process efficiency and plan process improvement;
• control and share these data;
• provide presentations and analyses of information that serve business lines;
• rely on qualified data to forecast or predict by managing activities through anticipation.
Agile Transformation through Business Intelligence, which we are now discussing, is a matter of mindset, methods, and organization.
1. The Agile Transformation mindset
If you are of the opinion that a company needs to improve and transform itself every day without waiting for a failure to occur, then you have the right mindset.
So as soon as it appears that something needs to be improved in the delivery of Business Intelligence services, you will want to identify it, understand it, and solve it, as soon as possible and while minimizing the cost of the resources mobilized.
This is the meaning of agile transformation.
It requires constant business vigilance and the certainty that an identified case will resonate with all the contributors involved.
It also presupposes that the company’s culture is homogeneous in terms of its aspiration to continuously improve through the best possible production of information, and that each person understands their role and responsibility with regard to their expected contribution through clear and shared processes.
If this is not yet the case in your organization but you feel it is ripe for change, then you will understand the importance of the following points.
2. Agile Transformation methods
When we hear "agile," the minds of computer scientists and users who have participated in digital projects hear "agile method, Scrum, sprint, etc." Sometimes, some of that is indeed involved, but that’s not quite the point, and it’s not all about the development of applications or data products.
Agile Transformation methods consist in continuously delivering additional value without abruptly challenging cultural, organizational or technological achievements.
They can also anticipate more structuring projects, so that they can be approached in "change management" mode, at the pace necessary for their adoption by the key players involved, and without making too many brutal budgetary sacrifices.
A key word in this agile transformation is "roadmap."
You should consider that improving your company’s B.I. is a door that is opened when you become aware of its many projects and milestones... and that you will never close this door again!
It becomes a fundamental process that must be described, shared and monitored to adapt it to changes in the context of your business lines, organization, and technologies, and determine the resources that can be devoted to it.
The methods applicable to this undertaking are those found in industry, urban planning, and all sectors where efforts are being made to ensure the progress and sustainability of a production system. Thus, for the data component, the system generates data products that must create value and drive progress throughout the life of the company. These data products reflect some uses of information that we have managed to systematize, as well as others that we are planning to serve through B.I.
Your transformation roadmap and product portfolio
The business assets produced and maintained by this roadmap are therefore a portfolio of data products and underlying data assets.
To clarify, data products tend to take the form of self-service reports, dashboards, guided analyses, and viewpoints.
Data assets, on the other hand, are documented and qualified datasets that are used to enhance data products.
Some are specifically built for a particular product, while others are datasets common to a greater or lesser number of direct (products are sourced directly from them) or indirect (they serve as basic data for transformation processes for previous datasets) uses. These data assets are documented in the famous data catalogs, which have become essential for the proper maintenance of a B.I. system.
Your roadmap is the path that your company plans to take to implement and maintain its data products and also to transform its context to derive more value from these products; your portfolio of data products represents, in a way, the "management of the stock" of uses served and to be served by B.I.
It is a bit like managing a real estate program, where the questions to be asked include: what? for whom? with whom? when? how much? what expected benefit? what status? what priority?
The two tools taken together are a framework for coordination between your management, business lines, and IT department. The first two methods mentioned are therefore roadmap management and data product portfolio management.
Taking business requirements into account
The very purpose of B.I. is to meet the information needs of your business lines. Boosting the desire for progress by providing more information to inform decision-making means ensuring that all the needs expressed are taken into account and are dealt with in a timely manner.
The overall process does not involve the business issuer at all stages, but they must remain informed of the different stages of their request, regardless of its outcome: full satisfaction, rejection, negotiated adaptation, delay, etc.
Each organization will adapt the process based on its own strategy and resources, but the processing of the request is a structuring process to determine the roles and responsibilities of each of the contributors, up to the delivery of the potential final data product and the provision of the corresponding support.
But from the outset, to avoid developing data products in a disorganized or redundant manner, the first steps in the processing of a request will require:
- an owner responsible for the processing of the request
- a discussion on the precise definition of the request
- a verification of the existing data assets/products to serve it (see documentation method)
- an assessment of the benefits of the request
- an assessment of the data product’s feasibility
- an evaluation of the cost of the expected data product
The processing system must be documented and traceable. As soon as the request is accepted, the potential data product should be integrated into the product portfolio.
The design (and evolution) of data products
It is during the design phase that you will find the collaborative business/IT aspect of the sprints so dear to agile methods.
It is important to involve the users most representative of the expected use and work on the experience that best corresponds to the ergonomics, kinematics, presentation and semantics that will determine the performance of the service to be delivered by the data product.
You work on a model as close as possible to the final tool, you show the results as quickly as possible, and you proceed by rapid iterations until you have express validation.
If the data product is complex, you plan multiple sprints to settle each precise point of mutual understanding, without losing sight of the product’s overall coherence.
Ideally, you should form highly involved business/IT pairs that work side by side as often as possible.
You put the product to the test of use as soon as possible, even if it is a minimum viable product (MVP), as long as it contains the main expected functionalities or at least the most critical ones for a mutual business/IT understanding of the product-related challenges.
You should not hesitate to deploy closely monitored pilot phases. And you should respond as quickly as possible to any problems encountered and suggestions made.
Agile release (DevOps/DataOps)
Release "trains" for new application chains or modifications (upgrades/corrections) are often a severe hindrance to business lines perceiving that the new value is available as functional and ergonomic validations are carried out.
This is one of the arguments preferred by business departments that are over-equipped with mixed functional and technical skills, to maintain a form of shadow IT or to sustain pilot situations. It is a way to avoid releasing into production, which is considered too slow, and guarantee the responsiveness of the upgrades close to users. It is a frequent drift that penalizes IT/business collaboration and can be very costly and constitute a form of unsuspected application "debt."
This essentially technical DevOps process is probably one of the most complicated and misunderstood in Business Intelligence. It is difficult for business lines to assess the impact of the desired new functionality in production: in fact, the value provided by a new data product is not necessarily proportional to the technical difficulty of its insertion in the IT production landscape.
Obviously, the more the use required finding new data, making complex transformations, or adding software or infrastructure components, the more the impact on the release time will be felt.
Companies must therefore often reform their capacity to respond to these implementations, without sacrificing the rigor and security of this discipline which often involves specialized and very diverse technical skills.
Project management
Managing a project above all means delivering the expected result within the planned budget and time frame and if possible, doing so in a way that is even better, faster and cheaper!
In addition to the use of appropriate tools in line with the project’s complexity, excellence in management is based on the determination to have the right resources intervene at the right time on the different tasks set out in the schedule.
When the expected product has been perfectly specified or even advanced to a detailed design level and the business line has been involved right up to the implementation schedule, management follows a set path.
Most of the time, the initial schedule has to be adapted, for multiple reasons, and often very early on if the project is managed well, since the disruptive elements of the schedule can often be determined only once the project has started.
The project manager’s skill lies in their ability to rearrange the schedule, resources and budget, or even reduce the project to a more basic form, even if this means planning successive or staggered batches.
Working as close as possible to the business and IT correspondents who must remain involved throughout the project, they need to ensure that a course is maintained, even if this sometimes has to be renegotiated, with clients and internal resources and inevitable subcontracted resources.
The data product design chain is full of pitfalls, and project management itself must be both rigorous and flexible. Priorities can change quickly, as can the availability of resources.
It is therefore essential to consider that all or parts of the project can be defined according to different methods of implementation. These methods often depend on the nature of the contract with consulting and service providers: in flat-rate mode, in technical assistance mode, or in "project" or "service center" mode, for example.
Considering this as early as possible and providing for Plan Bs is a guarantee of flexibility enabling the project’s management to be adapted to its potentially evolving context.
Research and design of new business cases
The rise of data science over the past decade has led company decision-makers to innovate around data and even "monetize" it. This led to a blessed era for consulting firms, where they helped business lines find new and, if possible, disruptive business cases.
Beyond the fad phenomenon and hopes of a business nugget discovered by serendipity ("run algorithms on all kinds of data and you’ll find treasures you never imagined"), organizations have felt a need for data mining. Many have set up teams (or squads – it sounds more elegant) of data engineers and data scientists in charge of helping or encouraging business lines to work together on the available data (internal and especially external) that could reveal new drivers for improving business, processes, or even promising diversifications.
In a context of strong external and internal changes in companies and mindsets, counting on the contribution of more digital-native employees and an ever more impressive volume of contextual data, it is important to take a step back to break with old habits.
Discovery workshops or data labs can support this type of approach, and it is important to understand to what extent the principles of design thinking, for example, can help an organization question its processes based on a better understanding of data.
This is also an excellent way to immerse business populations in the logical data models that they often use imperfectly or incompletely: it is a strong driver for improving their data culture applied to their business line.
Communication, training and facilitation
I can imagine some of you smiling: when we talk about communication and facilitation in an IT context, we are often not taken very seriously!
In our case, these are undoubtedly some of the most important drivers for making your company effective from the start of the data project, and for sustaining efforts in the long term:
- Communication: share information on your strategy, objectives, roadmap, projects, tools, successes, delays, changes in organization, processes, etc. And make everyone autonomous in their access to this information. Both organize "pushing" (periodic publications, internal events, etc.) and promote "pulling" (portal, collaborative spaces, tutorials, testimonials, organized content management).
Continually remind people of the value and ease of accessing the complete documentation of the B.I. system. It should be organized both to simplify its gradual updating by each of the business and IT contributors, and to make its exploratory analysis efficient and immediate (structuring, search engines, ergonomics of rankings, glossaries, catalogs, product portfolio, etc.).
- Training: define the awareness-raising and training courses to be systematized according to the different profiles and guarantee that the company’s data culture is real, shared, and even unique.
This important factor for employee pride should not be overlooked, as it leads to recognition, responsibility, company spirit, a feeling of serving a group, and the discovery of "others."
It is also necessary to update forgotten training courses, provide for the upgrading of skills when roles change, and hire new employees with the right level of competence for their new responsibilities.
- Facilitation: bring engagement to the desired level, maintain it over time and ensure the inevitable rotation of contributors in different roles, track any loss of motivation, and do not hesitate to re-distribute roles to avoid running out of steam.
Identify facilitators and "drivers," follow up with sponsors, and involve them on a regular basis.
Recognize and value each individual’s contributions.
Take the pulse of communities and help them define their own roadmap towards satisfaction in all cases!
3. Organizing your Agile Transformation
If your company has defined a strategy with objectives, it must then ensure it has the means to achieve them.
The most delicate subject is the organization and resources that will drive your transformation.
Although there is no typical organization, we can note that the most advanced companies share a common vision around some simple principles:
1. If you want your culture to be shared and effective, you need to:
- distribute roles to as many people as possible
- keep to the minimum the creation of full-time positions dedicated to the continuous transformation of the data project
- recognize that this transformation will have an additional cost compared to the initial situation
2. If you want your transformation to promote active and ongoing collaboration between business lines and IT and serve the company’s strategy, it must be driven by a cross-functional authority:
- that manages the objectives set out in the data strategy and derives its own milestones for action
- that oversees and coordinates the collaboration between business lines and IT
- that reports to the management of the organization (Executive Committee, board, etc.)
3. If you want your company to align itself on the data subject behind an ad hoc authority, without hierarchical power over the company’s other departments, you need a strong commitment from the management and an identified and committed sponsor within the Executive Committee
4. If the aim is to distribute the roles in the transformation to the largest possible number of contributors, you need to :
- you need to organize common interest groups into communities and ensure that they all have goals that support the company’s data strategy.
- you need to recognize that these roles will affect the contributors’ load as compared with their initial workload and quantify the time allocated to these roles.
In a few lines, here are the principles that have allowed us to legitimize a collaborative organization that is superimposed on a company’s hierarchical organization charts and is centered around the key role of the Chief Data Officer and their Data Office, as illustrated (very roughly) in the diagram below.
These are the basic principles. We hope that they are an easy-to-understand illustration for everyone in your organization and that throughout this series of articles, we have helped you assimilate concepts that are often mentioned, but rarely presented end-to-end.
We have done this in order to achieve overall consistency around what many call "data-driven" enterprises.
You will have understood that, beyond wishful thinking, there are many things you can think about and implement to reach this noble objective.
Our clients know that this is an essential project and that it must be approached with realism and perseverance, and that the visible gains are the result of many small steps of progress. It is about striking the right balance between ambition and realism.
Read also : other articles about our offers
La Business Intelligence en 3 étapes
Process Intelligence : comprendre comment les données circulent
Data Intelligence : rendre la data disponible
Advanced Analytics : s'adapter à son public
Performance Management : choisir les bons KPI
