Industries
|
|
|
Before my nervous system decided to depart for Pago Pago, I did swing dancing for over fifteen years. My favorite dance within that genre all grows out of a simple basic step I could tech you in five minutes. (Learn something about its history through parts one, two, three, four, and five.)
Back in the day, people could tell what high school you went to by the way you did your basic.
Individuals and groups solve problems in different ways, driven by their experience and preferences, and also by the nature of the problem and its potential solutions.
There are a zillion different ways of doing things, and you can spend a lifetime getting better, adding variations, and doing all the other things possible in a dance, but we have to start somewhere.
I'm going to show you one business analysis "basic," which is based on my many decades of building and employing computer simulations.
For this initial discussion, we're going to talk about the process of building a simulation of a system that already exists.
The simulation will be used to improve the operation of the existing system.
The system does not have to be real-time or interactive.
The existing system is a process consisting of multiple steps (think of a flowchart, possibly with branches), and not a single entity.
The process I describe can be done alone, but most work of any scale will involve groups.
Working with multiple people and groups involves communication — and empathy.
Define terms. Learn how to speak each other's language.
Understand that you won't get it right the first time. Listen, document, review, correct. Repeat this process until all parties reach agreement.
Analysis and solution happen within a managed environment of limited resources. Understand the context and how to generate the best results.
There are many reasons to write and run simulations. I listed some industries and applications on the third page.
Simulations have to provide some kind of value, or else there is no reason to build them.
The simulation has to be accurate enough to be meaningful. Remember that all simulations are wrong; some are useful.
The use(s) of the simulation may be expanded, limited, or otherwise modified as more is learned through the process.
Discover what the existing system does, what components make it up, and the actions that take place within it. These are your nouns and verbs.
Collect the data that characterize the system. These are your adjectives and adverbs.
The organization has needs, customers have needs, users have needs, and designers and analysts have needs.
The solution may have needs of its own. We may learn about those needs at any point in the process, but the earlier we know, the easier it will likely be to make allowances.
We need to understand the difference between what the solution DOES and what the solution IS. The latter describe qualities the solution should have. For example, two solutions may generate the same answer, but the one that is simpler to use, runs faster, requires less maintenance, and is easier to modify will be preferred.
Define the criteria by which the requirements are agreed to be met.
The solution should simulate everything that the existing system does — unless all parties agree that things can be omitted or simplified.
There are many (very good) reasons to make assumptions and simplifications, but they should all be understood, agreed to, and documented. The risks and impacts should also be understood.
There are many ways to evaluate and rank solutions. They may differ based on the organization and application.
A classic way to compare solutions is by the net present value they provide after cost-benefit analyses are performed.
However, not all criteria can be reduced to monetary figures, and all organizations are not bound by the same incentives.
The full solution package should consider construction, operation, deployment, training, maintenance, and more.
Solutions should generally be as simple as possible — but no simpler. Remove complexity whenever possible, but retain all required functionality. Avoid adding features that aren't needed out of a sense of "completeness" or because they're "cool."
Solutions may need to be implemented in phases.
Training, documentation, and ongoing management and maintenance are part of the solution.
I generally strive to make solutions as standardized and modular as possible. That said, it takes time to learn how to do that.
Initial solutions in a problem space tend to be custom, expensive, and brittle. They become standardized, cheaper, and robust over time. Think cars!
EVERY aspect of a solution should be tested, alone and in combination.
Testing should be planned for from the beginning (as much as possible).
Solutions should be evaluated on how they work — and how they address the stated problem.
Tests should meet defined standards that give pass/fail answers (as much as possible). Different kinds of tests are more amenable to this than others (Think TQM. What are the exceptions?).
Consider the entire solution process from the point of view of the tests it will have to pass (think Test-Driven Development - TDD).
Remember, the market provides the most important — and stringent — test of all. The best solution doesn't always win.
Link to detailed discussion.
Link to detailed discussion.
Regardless of the structure of the engagement, the activities in each phase are carried out in an iterative fashion that continuously incorporates review, feedback, and correction both within and between phases.
Link to detailed discussion.
This presentation and other information can be found at my website:
E-mail: bob@rpchurchill.com
LinkedIn: linkedin.com/in/robertpchurchill