Posts tonen met het label Business Analysis. Alle posts tonen
Posts tonen met het label Business Analysis. Alle posts tonen

dinsdag 21 februari 2023

How will ChatGPT affect the practice of business analysis and enterprise architecture?

 

ChatGPT (Chat Generative Pre-trained Transformer), is a language model-based chat bot developed by OpenAI enabling users to refine and steer a conversation towards a desired length, format, style, level of detail, and language.  Many of my colleagues are assessing the impact of Artificial Intelligence products on their practice and the jury is still out there: some of them consider it a threat that will wipe out their business model and others see it as an opportunity to improve productivity and effectiveness of their practice.



I have a somewhat different opinion. Language training models use gigantic amounts of data to train the models but I am afraid if you want to use the Internet data you certainly have a massive amount of data but of dubious and not always verifiable quality.

General Internet data is polluted with commercial content, hoaxes and ambiguous statements that need strong cultural background analysis to make sense of it.

The data that has better quality than general Internet data is almost always protected by a copyright; Therefore use without permission is not always gentlemanlike to say the least.

Another source of training data are the whitepapers and other information packages you get in exchange for your data: e-mail, function, company,… These documents often start with stating a problem in a correct and useful way but then direct you to the solution delivered by their product.

The best practices in business analysis and enterprise architecture are -I am afraid- not on the Internet. They’re like news articles behind a paywall. So if you ask CHAT GPT a question like “Where can I find information to do business analysis for analytics and business intelligence?” You get superficial answers that –at best- provide a starting point to study the topic.


A screenshot of the shallow and casual reply. It goes on with riveting advice like “Stay Informed”, “Training and Certification”, “Networking”, “Documentation”,…

And the question “What are Best Practices in business intelligence” leads to the same level of platitudes and triteness:

  • “Align with business goals” who would have thought that?
  • “User involvement and collaboration” Really?
  • “Data Quality and Governance” Sure, but how? And when and where?

In conclusion: a professional analyst or enterprise architect has nothing to fear from ChatGPT. 


At best, it provides a somewhat more verbose and redacted answer to a question saving you the time to plough through over a billion answers from Google.


vrijdag 1 maart 2019

About Ends and Means, or Beginning and Ends...


It has been a while since I published anything on this blog. But after having been confronted with organisations that –from an analytics point of view- live in the pre-industrial era, I need to get a few things off my chest.
In these organisations (and they aren’t the smallest ones)  ends and means are mixed up, and ends are positioned as the beginning of Business Intelligence. Let me explain the situation.

Ends are the beginning



sea ice
A metaphor for a critical look at reporting requirements is like watching heavy drift ice 
and wondering whether it’s coming from a land based glacier or from an iceberg...

Business users formulate their requirements in terms of reports. That’s OK, as long as someone, an analyst, an architect or even a data modeller understands this is not the end of the matter, on the contrary.
Yet too many information silos have been created when this rule is ignored. If an organisation considers report requirements as the start of a BI project they are skipping at least the following questions and the steps needed to produce a meaningful analytics landscape that can stand the test of time:

  • New information silos emerge with an end-to-end infrastructure to answer a few specific business questions leaving opportunities for a richer information centre unexplored.
  • The cost per report becomes prohibitive. Unless you think € 60.000 to create one (1) report is a cinch…
  • Since the same data elements run the risk of being used in various data base schemas, the extract and load processes pay a daily price in terms of performance and processing cost.

Ends and means are mixed up


A report is the result of an analytical process, combining data for activities like variance analysis, trend analysis, optimisation exercises, etc.. As such it is a means to support decision making; so rather than accepting the report requirements as such, some reverse engineering is advised:

What are the decisions to be made for the various managerial levels, based on these report requirements?

You  may wonder why this obvious question needs to be asked but be advised, some reports are the equivalent of a news report. The requestor might just want to know about what happens without ever drawing any conclusions let alone linking any consequences to the data presented.

What are the control points needed by the controller to verify aspects of the operations and their link to financial results?

Asking this question almost always leads to extending the scope of the requirements. Controllers like to match data from various sources to make sure the financial reports reflect the actual situation.

What are the future options, potential requirements and / or possibilities of the required enhanced with the available data in the sources?

This exercise is needed to discover analytical opportunities which may not be taken at the moment for a number of reasons like: insufficient historical data, lacking analytical skills to come up with meaningful results… But that must not stop the design from taking the data in scope from the start. Adding the data in a later stage will come at a far greater cost than the cost of the scope extension.

What is the basic information infrastructure to facilitate the above? I.e. what is the target model?

A Star schema is the ideal communication platform between business and tech people.
Whatever modelling language you use, whatever technology you use (virtualisation, in memory analytics, appliances, etc…) in the end the front end tool will build a star schema. So take the time to build a logical data star schema model that  can be understood by both technical people and business managers.

What is the latency and the history needed per decision making horizon?

The latency question deals with a multitude of aspects and can take you to places you weren’t expecting when you were briefed about report requirements. As a project manager I’d advise you to handle with care as the scope may become unmanageable. Stuff like (near) real-time analytics, in database analytics, triple store extensions to the data warehouse, complex event processing mixing textual information with numerical measures… But as an analyst I’d advise you to be aware of the potentially new horizons to explore.
The history question is more straightforward and deals with the scope of the initial load. The slower the business cycle, the more history you need to load to come up with useful data sets for time series analysis.

What data do we present via which interface to support these various decision types?

This question begs a separate article but for now, a few examples should make things clear.
Static reports for external stakeholders who require information for legal purposes,
  • Reports using prompts and filters for team leaders who need to explore the data within predetermined boundaries,
  • OLAP cubes for managers who want to explore the data in detail and get new insights,
  • A dashboard for C- level executives who want the right cockpit information to run the business,
  • Data exploration results from data mining efforts to produce valid, new and potentially useful insights in running the business.

If all these questions are answered adequately, we can start the data requirements collection as well as the source to target mappings.



Three causes, hard to eradicate


If your organisation shows one or more of these three causes, you have a massive change management challenge ahead that will take more than a few project initiation documents to remedy. If you don’t get full support from top management, you’d better choose between accepting this situation and become an Analytics Sisyphus or look for another job.

Project based funding

Government agencies may use the excuse that there is no other way but moving from tender to tender, the French proverb “les excuses sont faites pour s’en servir” [1] applies. A solid data and information architecture, linked to the required capabilities and serving the strategic objectives of a government agency can provide direction to these various projects.
A top performing European retailer had a data warehouse with 1.500 tables, of which eight (8!) different time dimensions. The reason? Simple: every BU manager had sovereign rule over his information budget and “did it his way” to quote Frank Sinatra.

Hierarchical organisations

I already mentioned the study of Prof. Karin Moser introducing three preconditions for knowledge co-operation: reciprocity, a long term perspective for the employees and the organisation and breaking the hierarchical barriers. [2]
On the same pages I quote the authors Leliveld & Vink and Davos & Newstrom who support the idea that knowledge exchange based on reciprocity can only take place in organisational forms that present the whole picture to their employees and that keep the distance between co-workers and the company’s vision, objectives, customers etc. as small as possible.
Hierarchical organisations are more about power plays and job protection than knowledge sharing so the idea of having one shared data platform for everyone in the organisation to extract his own analyses and insights is an absolute horror scenario.

Process based support

Less visible but just as impactful, if IT systems are designed primarily for process support instead of attending as well to the other side of the coin, i.e. decision support, then you have a serious structural problem. Unlocking value from the data may be a lengthy and costly process. Maybe you will find some inspiration in a previous article on this blog: Design from the Data.
In short: processes are variable and need to be flexible, what lasts is the data. Information objects like a customer, an invoice, an order, a shipment, a region etc… are far more persistent than the processes that create or consume instances of these objects.




 [1]    Excuses are made to be used
 [2]    Business Analysis for Business Intelligence pp. 35 -38 CRC Books, a Taylor & Francis Company October 2012






donderdag 19 april 2018

How to make progress in a political organisation

Why Business Analysis and politics don’t mix.


After thirty years of practice in all sorts and flavours of organisations there’s one that stands out as a tough conundrum for any business analyst and by extension enterprise architect as well as project managers. It’s the political organisation, so eloquently described by Henry Mintzberg. 
The problem with these organisations for a business analyst, project manager or enterprise architect is identical: setting priorities to determine the first iteration of the development cycle. This lack of priority ranking may lead to scope creep, projects that never deliver the product or a user community that is not on board, etc…


Forces in a political organisation

Wouldn't we all like to work in Tom Davenports Analytical Organisation?

In the paragraph “Decisions, Teams, and Groups at Work, Classification of Decision-Making Environments, I use a simple matrix to describe decision-making contexts for BI projects. But, believe me, you can use it for any project type.

You don’t need much time to determine if you’re in a political organisation. Look for committees that make the ultimate decisions, look for a lack of accountable individuals, slow decision making processes and a track record of projects that failed to deliver the intended product. Of course government bodies are by definition political but you will also find them in the private sector.

How to recognise a political organisation before you’re even at the reception desk?

Maybe this table can help:



Political organisations, by definition, don’t have shared goals. Each alderman, state secretary, each manager, wants to score his goals without letting the team take any credit for it. Because re-election or promotion matter… And political organisations always differ on the cause and effect chains which shows clearly in analytical projects.

Setting priorities in a political organisation


You can imagine that this is the toughest conundrum to solve; if you can’t prioritise “because everything is important” you can’t even start an analysis track. Unless you simply want to sell billable hours… And prepare for a debriefing and passing the buck, dodging any responsibility.
But if you’re a hired gun that may be exactly why you’ve been hired: to take the blame for the organisation’s ineptness to take responsibility and make choices even if they go against some members of the team. (I use “team” for want of a better word in a political organisation)
In this post, I am giving you a few tips and tricks to force the “team” to come up with priorities.

But first some context. The organisation is looking for a new way to analyse structured and unstructured data; Therefore it needs a modern data architecture. Your job as business analyst (and by extension project manager and enterprise architect) is to know what the strategic priorities of the organisation are.  This needs to match with the available data and information needs. You need to check the feasibility and then choose the first iteration to deliver analytical results.  A best practice is to check the organisation’s strategy, its initiatives to improve the organisation’s position in case of a commercial entity or the level of societal utility in case of a governmental or non for profit organisation.
Imagine the first intake with the project sponsor, the product owner and any other stakeholder who has been identified in the project structure.

Here’s the dialogue:

Business Analyst: At the kick off of this analysis track, I’d like to determine with you the first iteration: where we start analysing, designing and building the first deliverables.
The “team”: (silence)
Business Analyst: Do you have a project portfolio and do you use program management to prioritise the management actions? Do you have mission and vision statement for this project?
The “team”: We thought you could formulate the vision and the mission for the project. And no we don’t have a project portfolio. We do have an Excel sheet with a list of all the projects and their status.
Business Analyst: Could we infer from the status what the priorities are?
The “team”: No.
Business Analyst: What if we look at the budget per management project. Maybe the size says something about the priority? Or what if look at rejected project proposals and the reasons? Maybe that says something about the criteria.
The “team”: Not necessarily. First of all, all management project requests are answered positively and funds are allocated to these projects. Some projects may have big budgets but that doesn’t indicate anything about their importance.
Business Analyst: What about the number of full time equivalents allocated to each project?
The “team”: A high number may indicate something about the complexity or the scope but that doesn’t tell you what priority the project has.
Business Analyst: I think this one may help us out: have you indicated the origins of leakages and losses in your business processes and could those numbers give us a hint of what’s important to the management team?
The “team”: Leaks and losses are handled by the management team and as such are equally important.
Business Analyst: Does the amount of data, the connection with business processes and the variety in the data give us a clue where we should start the project?
The “team”: That’s we are hiring you as a Business Analyst.

Now it gets tricky and you make the call, as The Clash sing: “Should I stay or should I go”

Here are few of the killer questions and remarks that will lead you to the exit:

  • What projects will get or got the most press coverage?
  • What if you had to choose, right now?
  • Do you expect me to deliver a successful end result if you don’t know what you want?



 

More on decision making contexts in the book “Business Analysis for Business Intelligence” p. 203 – 213 


Is there way out? Maybe.



The only escape route I can think of is to start with a stakeholder analysis. Try defining the primary stakeholders and map them on a RACI matrix. If that works, you can develop your first iteration with some confidence, knowing that danger is always on the road ahead..

Example of a stakeholder analysis that turns out well: the CEO’s desk is where the buck stops.

If a stakeholder analysis is inconclusive, there must be someone who’s not involved in the official decision making unit (DMU) who is the primary influencer. Now you’ll have to get out of your comfort zone as an analyst and start thinking like an account manager.

I was lucky to have training in the Miller Heiman Strategic Selling method as well as the Holden Power Base Selling method. It sharpened my skills for identifying and influencing these hidden decision makers. So here’s my advice: check out these two books. They will increase your efficiency in political organisations with an order of magnitude.
Target account selling; Fox hunting

The new strategic selling is an update of the original, worth reading for any novice in business analysis and project management.
This is Jim Holden’s original book. Of course, as things go in this business, there were many to follow up on his success. Start here anyway.

zondag 22 november 2015

Book Review: Business Analysis

3rd Edition, edited by Debra Paul, James Cadle and Donald Yeates

Preamble: the island and the continental species

When BCS, the Chartered Institute for IT deems a book worth publishing, it is certainly worth reviewing from a continental point of view. Why? Because experience shows that the UK’s  business analyst has not exactly  the same profile as the variety on the mainland.
On the British Isles, a business analyst covers a much wider scope: “One of the most important aspects of a business analysis project is to decide what the focus is and which areas need to be investigated. For example, on some projects the focus may be to explore possible improvements on how part of the organization works. In this case, we might begin by examining all of the current working practices, including the staffing and job roles, and the work may focus on analysing and evaluating the options for the future business system. Another project may focus on the IT system needs and whilst understanding the situation and all of the stakeholder perspectives is important, the potential for the use of IT to improve the business system will dominate the analysis.” (p .59)
Clearly, the island species covers a far broader scope than the continental one. Of the hundreds of business analysts I have met on projects, in training courses and seminars, ninety percent come from an IT background. In the application or OLTP world, I have met with dozens of ex-developers who became functional analysts and expanded their horizon towards business analysis. In the OLAP or analytics world, there is dominant share of DBAs who became business analysts. Suddenly I realise that I am more of an island species as I evolved from sales, marketing and finance into business analysis and studied computer science to make sure I can communicate with the designers and developers.

A comprehensive introduction

The editors take you on a journey through the analysis practice, defining the concept, the competencies and introducing strategy analysis, business analysis as a process, touching the investigation techniques and introducing stakeholder analysis. After modelling the business process, defining the solution and making the business and financial case, the requirements are discussed as well as a brief introduction to modelling the requirements and delivering the requirements and the business solution.
Delivering this body of knowledge in fourteen chapters on 280 pages indicates this book is a foundation for practitioners.

Models, models and… models


The 280 page book is packed with models, 112 of them are illustrated and explained as well as integrated in a logical process flow of the business analysis practice.
In that sense, the foreword of president of the IIBA UK Chapter, Adrian Reed, hits the spot when he calls it “an extremely useful resource that will referenced by new and experienced practitioners alike”.
Novice analysts can use this book as an introduction to the business analysis practice in the broadest sense while experienced business analysts will consider it a valuable placeholder for useful frameworks, concepts and material for further study. The Reference and Further Reading sections at the end of each chapter contain extremely useful material.  With regards to “further reading”  there is a caveat I need to share with you. It‘s not about the book itself but more about models in general.

A caveat about models

Let me tell you a little story from my marketing practice to illustrate my point.
A very familiar model in portfolio management is the Boston Consultancy Group’s  Share Matrix. It is used on a strategic level to analyse business units and in the marketing practice, the product portfolio is often represented and analysed via this model.
For those not familiar with the model, here’s a little reference to the theory: https://en.wikipedia.org/wiki/Growth%E2%80%93share_matrix
When I worked for a multinational FMCG company I discovered what I called “Cinderella brands”. These were brands with a small market share, low growth and considered a dead end street for the marketer’s career. You could find product managers with little ambition in that position, fixing up and manoeuvring to keep the brand afloat while people higher up in the organization where waiting for the right moment to axe the brand. I managed to convince the people with the axe that an appropriate marketing approach cold not just save the brand but grow it into a profitable niche product, sometimes contributing more than their so-called cash cows. We built the business case on processed cheese with a budget on a shoestring and proved our point that a model can never take over from thorough analysis and critical thinking. After that, nobody mentioned “dogs” anymore, “Cinderella” became the household name for forgotten brands with unrealized potential. (And we got much more business from the multinational.)
The illustration below from an academic author shows exactly what can go wrong when models take over from scrutiny and  critical thinking.

These are the questions to ask when you look at a growth share market:
·          Who says cash cows don’t need substantial investment to maintain their dominant market share and keep up with market growth? Ask Nokia if you doubt it.
·           Who says dogs need to have a negative cash flow? Sure,  if your marketing spend is based on the same mental models as those for stars and cows you will be right but guerrilla marketing techniques may prove the  opposite.
·           Who says stars’ growth will continue for eternity? Ever read “Crossing the Chasm” by Geoffrey Moore? Especially in high tech marketing, novelties may only appeal to the techies but never reach the mainstream market…
In fact, question marks are in the only quadrant in the above model where some form of nuance can be observed…  Notice the expression “analyse … whether…”
In conclusion:  follow the editors’ further reading advice. It will help you to become a mature business analyst providing your customers not only the “know what” and some of the “know how” as described in the book, but also the “know why”. Wisdom may be harder to quantify but its value is beyond doubt in the business analysis practice. By the way, from the same editor, I recommend “Business Analysis Techniques” to increase your know how.

Regular updates needed

The business analysis practice evolves rapidly and the only criticism I can come up with is the lack of an accompanying website with extra updates and reference material. Let me add at least two of them:  a benefit map and the business canvass models are very much in the business analysis practice today.
To conclude, all you continental business analysts out there, buy the book and increase your knowledge by an order of magnitude.
Available at http://shop.bcs.org, paperback ISBN: 978-1-78017-277-4