| Zhamak Dehghani's "Data Mesh: Delivering Data-Driven Value at Scale" (2021) is a must read book for the data professional. So, here I am, finally managing to read it and give it some thought, even if it will probably take more time and a few more reads for the ideas to grow. Working in the fields of Business Intelligence and Software Engineering for almost a quarter-century, I think I can understand the historical background and the direction of the ideas presented in the book. There are many good ideas but also formulations that make me circumspect about the applicability of some assumptions and requirements considered. So, after data marts, warehouses, lakes and lakehouses, the data mesh paradigm seems to be the new shiny thing that will bring organizations beyond the inflection point with tipping potential from where organization's growth will have an exponential effect. At least this seems to be the first impression when reading the first chapters. |
||
|
The book follows to some degree the advocative tone of promoting that "our shiny thing is much better than previous thing", or "how bad the previous architectures or paradigms were and how good the new ones are" (see [2]). Architectures and paradigms evolve with the available technologies and our perception of what is important for businesses. Old and new have their place in the order of things, and the old will continue to exist, at least until the new proves its feasibility. The definition of the data mash as "a sociotechnical approach to share, access and manage analytical data in complex and large-scale environments - within or across organizations" [1] is too abstract even if it reflects at high level what the concept is about. Compared to other material I read on the topic, the book succeeds in explaining the related concepts as well the goals (called definitions) and benefits (called motivations) associated with the principles behind the data mesh, making the book approachable also by non-professionals. Built around four principles "data as a product", "domain-oriented ownership", "self-serve data platform" and "federated governance", the data mesh is the paradigm on which data as products are developed; where the products are "the smallest unit of architecture that can be independently deployed and managed", providing by design the information necessary to be discovered, understood, debugged, and audited. It's possible to create Lego-like data products, data contracts and/or manifests that address product's usability characteristics, though unless the latter are generated automatically, put in the context of ERP and other complex systems, everything becomes quite an endeavor that requires time and adequate testing, increasing the overall timeframe until a data product becomes available. The data mesh describes data products in terms of microservices that structure architectures in terms of a collection of services that are independently deployable and loosely coupled. Asking from data products to behave in this way is probably too hard a constraint, given the complexity and interdependency of the data models behind business processes and their needs. Does all the effort make sense? Is this the "agility" the data mesh solutions are looking for? Many pioneering organizations are still fighting with the concept of data mesh as it proves to be challenging to implement. At a high level everything makes sense, but the way data products are expected to function makes the concept challenging to implement to the full extent. Moreover, as occasionally implied, the data mesh is about scaling data analytics solutions with the size and complexity of organizations. The effort makes sense when the organizations have a certain size and the departments have a certain autonomy, therefore, it might not apply to small to medium businesses. Previous Post <<||>> Next Post References: |
|||
13 March 2024
Book Review: Zhamak Dehghani's Data Mesh: Delivering Data-Driven Value at Scale (2021)
12 March 2024
Systems Engineering: A Play of Problems (Much Ado about Nothing)
Disclaimer: This post was created just for fun. No problem was hurt or solved in the process!
Updated: 12-Jun-2024
On Problems
Everybody has at least a problem. If somebody doesn’t have a problem, he’ll make one. If somebody can't make a problem, he can always find a problem. One doesn't need to search long for finding a problem. Looking for a problem one sees problems.
Not having a problem can easily become a problem. It’s better to have a problem than none. The none problem is undefinable, which makes it a problem.
Avoiding a problem might lead you to another problem. Some problems are so old, that's easier to ignore them.
In every big problem there’s a small problem trying to come out. Most problems can be reduced to smaller problems. A small problem may hide a bigger problem.
It’s better to solve a problem when is still small, however problems can be perceived only when they grow bigger.
In the neighborhood of a problem there’s another problem getting closer. Problems tend to attract each other.
Between two problems there’s enough place for a third to appear. The shortest path between two problems is another problem.
Two problems that appear together in successive situations might be the parts of the same problem.
A problem is more than the sum of its parts.
Any problem can be simplified to the degree that it becomes another problem.
The complementary of a problem is another problem. At the intersection/reunion of two problems lies another problem.
The inverse of a problem is another problem more complex than the initial problem.
Defining a problem correctly is another problem. A known problem doesn’t make one problem less.
When a problem seems to be enough, a second appears. A problem never comes alone. The interplay of the two problems creates a third.
Sharing the problems with somebody else just multiplies the number of problems.
Problems multiply beyond necessity. Problems multiply beyond our expectations. Problems multiply faster than we can solve.
Having more than one problem is for many already too much. Between many big problems and an infinity of problems there seem to be no big difference.
Many small problems can converge toward a bigger problem. Many small problems can also diverge toward two bigger problems.
When neighboring problems exist, people tend to isolate them. Isolated problems tend to find other ways to surprise.
Several problems aggregate and create bigger problems that tend to suck within the neighboring problems.
If one waits long enough some problems will solve themselves or it will get bigger. Bigger problems exceed one's area of responsibility.
One can get credit for a self-created problem. It takes only a good problem to become famous.
A good problem can provide a lifetime. A good problem has the tendency to kick back where it hurts the most. One can fall in love with a good problem.
One should not theorize before one has a (good) problem. A problem can lead to a new theory, while a theory brings with it many more problems.
If the only tool you have is a hammer, every problem will look like a nail. (paraphrasing Abraham H Maslow)
Any field of knowledge can be covered by a set of problems. A field of knowledge should be learned by the problems it poses.
A problem thoroughly understood is always fairly simple, but unfairly complex. (paraphrasing Charles F Kettering)
The problem solver created usually the problem.
Problem Solving
Break a problem in two to solve it easier. Finding how to break a problem is already another problem. Deconstructing a problem to its parts is no guarantee for solving the problem.
Every problem has at least two solutions from which at least one is wrong. It’s easier to solve the wrong problem.
It’s easier to solve a problem if one knows the solution already. Knowing a solution is not a guarantee for solving the problem.
Sometimes a problem disappears faster than one can find a solution.
If a problem has two solutions, more likely a third solution exists.
Solutions can be used to generate problems. The design of a problem seldom lies in its solutions.
The solution of a problem can create at least one more problem.
One can solve only one problem at a time.
Unsolvable problems lead to problematic approximations. There's always a better approximation, one just needs to find it. One needs to be o know when to stop searching for an approximation.
There's not only a single way for solving a problem. Finding another way for solving a problem provides more insight into the problem. More insight complicates the problem unnecessarily.
Solving a problem is a matter of perspective. Finding the right perspective is another problem.
Solving a problem is a matter of tools. Searching for the right tool can be a laborious process.
Solving a problem requires a higher level of consciousness than the level that created it. (see Einstein) With the increase complexity of the problems one an run out of consciousness.
Trying to solve an old problem creates resistance against its solution(s).
The premature optimization of a problem is the root of all evil. (paraphrasing Donald Knuth)
A great discovery solves a great problem but creates a few others on its way. (paraphrasing George Polya)
Solving the symptoms of a problem can prove more difficult that solving the problem itself.
A master is a person who knows the solutions to his problems. To learn the solutions to others' problems he needs a pupil.
"The final test of a theory is its capacity to solve the problems which originated it." (George Dantzig) It's easier to theorize if one has a set of problems.
A problem is defined as a gap between where you are and where you want to be, though nobody knows exactly where he is or wants to be.
Complex problems are the problems that persist - so are minor ones.
"The problems are solved, not by giving new information, but by arranging what we have known since long." (Ludwig Wittgenstein, 1953) Some people are just lost in rearranging.
Solving problems is a practical skill, but impractical endeavor. (paraphrasing George Polya)
"To ask the right question is harder than to answer it." (Georg Cantor) So most people avoid asking the right question.
Solve more problems than you create.
They Said It
"A great many problems do not have accurate answers, but do have approximate answers, from which sensible decisions can be made." (Berkeley's Law)
"A problem is an opportunity to grow, creating more problems. [...] most important problems cannot be solved; they must be outgrown." (Wayne Dyer)
"A system represents someone's solution to a problem. The system doesn't solve the problem." (John Gall, 1975)
"As long as a branch of science offers an abundance of problems, so long is it alive." (David Hilbert)
"Complex problems have simple, easy to understand, wrong answers." [Grossman's Misquote]
"Every solution breeds new problems." [Murphy's laws]
"Given any problem containing n equations, there will be n+1 unknowns." [Snafu]
"I have not seen any problem, however complicated, which, when you looked at it in the right way, did not become still more complicated." (Paul Anderson)
"If a problem causes many meetings, the meetings eventually become more important than the problem." (Hendrickson’s Law)
"If you think the problem is bad now, just wait until we’ve solved it." (Arthur Kasspe) [Epstein’s Law]
"Inventing is easy for staff outfits. Stating a problem is much harder. Instead of stating problems, people like to pass out half- accurate statements together with half-available solutions which they can't finish and which they want you to finish." [Katz's Maxims]
"It is better to do the right problem the wrong way than to do the wrong problem the right way." (Richard Hamming)
"Most problems have either many answers or no answer. Only a few problems have a single answer." [Berkeley's Law]
"Problems worthy of attack prove their worth by fighting back." (Piet Hein)
Rule of Accuracy: "When working toward the solution of a problem, it always helps if you know the answer."
Corollary: "Provided, of course, that you know there is a problem."
"Some problems are just too complicated for rational logical solutions. They admit of insights, not answers." (Jerome B Wiesner, 1963)
"Sometimes, where a complex problem can be illuminated by many tools, one can be forgiven for applying the one he knows best." [Screwdriver Syndrome]
"The best way to escape from a problem is to solve it." (Brendan Francis)
"The chief cause of problems is solutions." [Sevareid's Law]
"The first step of problem solving is to understand the existing conditions." (Kaoru Ishikawa)
"The human race never solves any of its problems, it only outlives them." (David Gerrold)
"The most fruitful research grows out of practical problems." (Ralph B Peck)
"The problem-solving process will always break down at the point at which it is possible to determine who caused the problem." [Fyffe's Axiom]
"The worst thing you can do to a problem is solve it completely." (Daniel Kleitman)
"The easiest way to solve a problem is to deny it exists." (Isaac Asimov)
"The solution to a problem changes the problem." [Peers's Law]
"There is a solution to every problem; the only difficulty is finding it." [Evvie Nef's Law]
"There is no mechanical problem so difficult that it cannot be solved by brute strength and ignorance. [William's Law]
"Today's problems come from yesterday’s 'solutions'." (Peter M Senge, 1990)
"While the difficulties and dangers of problems tend to increase at a geometric rate, the knowledge and manpower qualified to deal with these problems tend to increase linearly." [Dror's First Law]
"You are never sure whether or not a problem is good unless you actually solve it." (Mikhail Gromov)
More quotes on Problem solving at QuotableMath.blogpost.com.
Resources:
Murphy's laws and corollaries (link)
14 February 2024
Business Intelligence: A One Man Show VI (The Lakehouse Perspective)
 |
| Business Intelligence Suite |
Continuing the ideas on Christopher Laubenthal's article "Why one person can't do everything in the data space" [1] and why his analogy between a college's functional structure and the core data roles is poorly chosen. In the last post I mentioned as a first argument that the two constructions have different foundations.
Secondly, it's a matter of construction, namely the steps used to arrive from one state to another. Indeed, there's somebody who builds the data warehouse (DWH), somebody who builds the ETL/ELT pipelines for moving the data from the sources to the DWH, somebody who builds the sematic data model that includes business related logic, respectively people who tap into the data for reporting, data visualizations, data science projects, and whatever is still needed in the organization. On top of this, there should be somebody who manages the DWH. I haven't associated any role to them because one of the core roles can be responsible for more than one step.
In the case of a lakehouse, it is the data engineer who moves the data from the various data sources to the data lake if that doesn't happen already by design or configuration. As per my understanding the data engineers are the ones who design and build the new lakehouse, move transform and manage the data as required. The Data Analysts, Data Scientist and maybe some Information Designers can tap then into the data. However, the DWH and the lakehouse(s) are technologies that facilitate their work. They can still do their work also if the same data are available by other means.
In what concerns the dorm analogy, the verbs were chosen to match the way data warehouses (DWH) or lakehouses are built, though the congruence of the steps is questionable. One could have compared the number of students with the numbers of data entities, but not with the data themselves. Usually, students move by themselves and occupy the places. The story tellers, the assistants and researchers are independent on whether the students are hosted in the dorm or not. Therefore, the analogy seems to be a bit forced.
Frankly, I covered all the steps except the ones related to Data Science by myself for both described scenarios. It helped that I knew the data from the data sources and the transformations rules I had to apply, respectively the techniques needed for moving and transforming the data, and the volume of data entities was manageable somehow. Conversely, 1-2 more resources in the area of data analysis and visualizations could have helped to bring more value to the business.
This opens the challenge of scale and it has do to with systems engineering and how the number of components and the interactions between them increase systems' complexity and the demand for managing the respective components. In the simplest linear models, for each multiplier of a certain number of components of the same type from the organization, the number of resources managing the respective layer matches to some degree the multiplier. E.g. if a data engineer can handle x data entities in a unit of time, then for hand n*x components are more likely at least n data engineers required. However, the output of n components is only a fraction of the n*x given the dependencies existing between components and other constraints.
An optimization problem resumes in finding out what data roles to chose to cover an organization's needs. A one man show can be the best solution for small organizations, though unless there's a good division of labor, bringing a second person will make the throughput slower until will become faster.
Previous Post <<|||>> Next Post
Resources:
[1] Christopher Laubenthal (2024) "Why One Person Can’t Do Everything In Data" (link)
13 February 2024
Business Intelligence: A One Man Show V (Focus on the Foundation)
 |
| Business Intelligence Suite |
I tend to agree that one person can't do anymore "everything in the data space", as Christopher Laubenthal put it his article on the topic [1]. He seems to catch the essence of some of the core data roles found in organizations. Summarizing these roles, data architecture is about designing and building a data infrastructure, data engineering is about moving data, database administration is mainly about managing databases, data analysis is about assisting the business with data and reports, information design is about telling stories, while data science can be about studying the impact of various components on the data.
However, I find his analogy between a college's functional structure and the core data roles as poorly chosen from multiple perspectives, even if both are about building an infrastructure of some type.
Firstly, the two constructions have different foundations. Data exists in a an organization also without data architects, data engineers or data administrators (DBAs)! It's enough to buy one or more information systems functioning as islands and reporting needs will arise. The need for a data architect might come when the systems need to be integrated or maybe when a data warehouse needs to be build, though many organizations are still in business without such constructs. While for the others, the more complex the integrations, the bigger the need for a Data Architect. Conversely, some systems can be integrated by design and such capabilities might drive their selection.
Data engineering is needed mainly in the context of the cloud, respectively of data lake-based architectures, where data needs to be moved, processed and prepared for consumption. Conversely, architectures like Microsoft Fabric minimize data movement, the focus being on data processing, the successive transformations it needs to suffer in moving from bronze to the gold layer, respectively in creating an organizational semantical data model. The complexity of the data processing is dependent on data' structuredness, quality and other data characteristics.
As I mentioned before, modern databases, including the ones in the cloud, reduce the need for DBAs to a considerable degree. Unless the volume of work is big enough to consider a DBA role as an in-house resource, organizations will more likely consider involving a service provider and a contingent to cover the needs.
Having in-house one or more people acting under the Data Analyst role, people who know and understand the business, respectively the data tools used in the process, can go a long way. Moreover, it's helpful to have an evangelist-like resource in house, a person who is able to raise awareness and knowhow, help diffuse knowledge about tools, techniques, data, results, best practices, respectively act as a mentor for the Data Analyst citizens. From my point of view, these are the people who form the data-related backbone (foundation) of an organization and this is the minimum of what an organization should have!
Once this established, one can build data warehouses, data integrations and other support architectures, respectively think about BI and Data strategy, Data Governance, etc. Of course, having a Chief Data Officer and a Data Strategy in place can bring more structure in handling the topics at the various levels - strategical, tactical, respectively operational. In constructions one starts with a blueprint and a data strategy can have the same effect, if one knows how to write it and implement it accordingly. However, the strategy is just a tool, while the data-knowledgeable workers are the foundation on which organizations should build upon!
"Build it and they will come" philosophy can work as well, though without knowledgeable and inquisitive people the philosophy has high chances to fail.
Previous Post <<||>> Next Post
Resources:
[1] Christopher Laubenthal (2024) "Why One Person Can’t Do Everything In Data" (link)
Business Intelligence: A One Man Show IV (Data Roles between Past and Future)
 |
| Business Intelligence Series |
The requirement for a Data Architect comes when there are several systems in place and there're multiple projects to integrate or build around the respective systems. It'a also the question of what drives the respective requirement - is it the knowledge of data architectures, the supervision of changes, and/or the review of technical documents? The requirement is thus driven by the projects in progress and those waiting in the pipeline. Conversely, if all the systems are in the cloud, their integration is standardized or doesn't involve much architectural knowledge, the role becomes obsolete or at least not mandatory.
The Data Engineer role is a bit more challenging to define because it appeared in the context of cloud-based data architectures. It seems to be related to the data movement via ETL/ELT pipelines and of data processing and preparation for the various needs. Data modeling or data presentation knowledge isn't mandatory even if ideal. The role seems to overlap with the one of a Data Warehouse professional, be it a simple architect or developer. Role's knowhow depends also on the tools involved, because one thing is to build a solution based on a standard SQL Server, and another thing to use dedicated layers and architectures for the various purposes. Engineers' number should be proportional with the number of data entities involved.
Conversely, the existence of solutions that move and process the data as needed, can reduce the volume of work. Moreover, the use of AI-driven tools like Copilot might shift the focus from data to prompt engineering.
The Data Analyst role is kind of a Cinderella - it can involve upon case everything from requirements elicitation to reports writing and results' interpretation, respectively from data collection and data modeling to data visualization. If you have a special wish related to your data, just add it to the role! Analysts' number should be related to the number of issues existing in organization where the collection and processing of data could make a difference. Conversely, the Data Citizen, even if it's not a role but a desirable state of art, could absorb in theory the Data Analyst role.
The Data Scientist is supposed to reveal the gems of knowledge hidden in the data by using Machine Learning, Statistics and other magical tools. The more data available, the higher the chances of finding something, even if probably statistically insignificant or incorrect. The role makes sense mainly in the context of big data, even if some opportunities might be available at smaller scales. Scientists' number depends on the number of projects focused on the big questions. Again, one talks about the Data Scientist citizen.
The Information Designer role seems to be more about data visualization and presentation. It makes sense in the organizations that rely heavily on visual content. All the other organizations can rely on the default settings of data visualization tools, independently on whether AI is involved or not.
Previous Post <<||>> Next Post
02 January 2024
Systems Engineering: Never-Ending Stories in Praxis (Quote of the Day)
 |
| Systems Engineering Cycle |
"[…] the longer one works on […] a project without actually concluding it, the more remote the expected completion date becomes. Is this really such a perplexing paradox? No, on the contrary: human experience, all-too-familiar human experience, suggests that in fact many tasks suffer from similar runaway completion times. In short, such jobs either get done soon or they never get done. It is surprising, though, that this common conundrum can be modeled so simply by a self-similar power law." (Manfred Schroeder, "Fractals, Chaos, Power Laws Minutes from an Infinite Paradise", 1990)
I found the above quote while browsing through Manfred Schroeder's book on fractals, chaos and power laws, book that also explores similar topics like percolation, recursion, randomness, self-similarity, determinism, etc. Unfortunately, when one goes beyond the introductory notes of each chapter, the subjects require more advanced knowledge of Mathematics, respectively further analysis and exploration of the models behind. Despite this, the book is still an interesting read with ideas to ponder upon.
I found myself a few times in the situation described above - working on a task that didn't seem to end, despite investing more effort, respectively approaching the solution from different angles. The reasons residing behind such situations were multiple, found typically beyond my direct area of influence and/or decision. In a systemic setup, there are parts of a system that find themselves in opposition, different forces pulling in distinct directions. It can be the case of interests, goals, expectations or solutions which compete or make subject to politics.
For example, in Data Analytics or Data Science there are high chances that no progress can be made beyond a certain point without addressing first the quality of data or design/architectural issues. The integrations between applications, data migrations and other solutions which heavily rely on data are sensitive to data quality and architecture's reliability. As long the source of variability (data, data generators) is not stabilized, providing a stable solution has low chances of success, no matter how much effort is invested, respectively how performant the tools are.
Some of the issues can be solved by allocating resources to handle their implications. Unfortunately, some organizations attempt to solve such issues by allocating the resources in the wrong areas or by addressing the symptoms instead of taking a step back and looking systemically at the problem, analyzing and modeling it accordingly. Moreover, there are organizations which refuse to recognize they have a problem at all! In the blame game, it's much easier to shift the responsibility on somebody else's shoulders.
Defining the right problem to solve might prove more challenging than expected and usually this requires several iterations in which the knowledge obtained in the process is incorporated gradually. Other times, one attempts to solve the correct problem by using the wrong methodology, architecture and/or skillset. The difference between right and wrong depends on the context, and even between similar problems and factors the context can make a considerable difference.
The above quote can be corroborated with situations in which perfection is demanded. In IT and management setups, excellence is often confounded with perfection, the latter being impossible to achieve, though many managers take it as the norm. There's a critical point above which the effort invested outweighs solution's plausibility by an exponential factor.
Another source for unending effort is when requirements change frequently in a swift manner - e.g. the rate with which changes occur outweighs the progress made for finding a solution. Unless the requirements are stabilized, the effort spirals towards the outside (in an exponential manner).
Finally, there are cases with extreme character, in which for example the complexity of the task outweighs the skillset and/or the number of resources available. Moreover, there are problems which accept plausible solutions, though there are also problems (especially systemic ones) which don't have stable or plausible solutions.
Behind most of such cases lie factors that tend to have chaotic behavior that occurs especially when the environments are far from favorable. The models used to depict such relations are nonlinear, sometimes expressed as power laws - one quantity varying as a power of another, with the variation increasing with each generation.
Previous Post <<||>> Next Post
Resources:
[1] Manfred Schroeder, "Fractals, Chaos, Power Laws Minutes from an Infinite Paradise", 1990 (quotes)
06 October 2023
Process Management: "Create Product" Process Diagram in Dynamics 365 for Finance & Operations
Introduction
A process
diagram should provide employees with a bird’s-eye view of the most important
steps needed to perform the process it describes. To be useful, the diagram
needs to be succinct, complete, accurate and descriptive enough. Unfortunately,
one needs to compromise to address all these requirements. Moreover, there are
further challenges, like where to set boundaries between activities and subprocesses,
or how much information to provide.
Dynamics
365 used to come with a set of standardized process descriptions and diagrams, at
least the support for the latter being interrupted. They were useful as overviews,
however sometimes they seemed to raise more questions than to clarify. On the
other hand, organizations implement only a subset from the functionality available,
and thus the process diagrams can vary between organizations. In theory, the
implementer or other service providers could help with a standardized set of
process diagrams designed for specific industries, though this may involve
further challenges.
Therefore,
organizations might be forced to start from scratch. Even then, the results
might not fulfill the expectations. At least in what process diagrams concern,
there seem to be a huge gap between theory and practice. Knowledge
representation in its various forms, and the process diagrams are included, can
be considered as an art or require more expertise and skills than usual.
Ideally, organizations
should have process diagrams for all business-critical processes. A more
relaxed approach could focus only on the important processes that need to be
performed occasionally, and for which refreshments are necessary. In this
category belongs the creation of master data, the creation of Products being
maybe the most complex one.
The ‘Create Product’ process was chosen to exemplify how a process diagram could be constructed and explain design choices and further aspects. (Click on the diagram to see the full-size version!)
As can be seen, the diagram starts with two subprocesses often omitted, even if they are quintessential for making sure that the next steps can be executed efficiently. The differentiation between activities and subprocesses was made based on the complexity of the steps and the responsibilities involved. When multiple steps need to be performed by other personas, then this might be a sign that a process or subprocess is involved. When other personas are involved, the blocks have different colors.
Another
important aspect is the use of succinct descriptions for each step. The building
blocks of the diagrams should be in theory enough, though that’s seldom the
case. To fill the gap the employee needs to navigate between the blocks and descriptions,
which is usually inefficient. Process management applications provide a better UI,
though contents’ navigability can be challenging as well.
Even if the
diagram attempts to generalize a Product’s creation, seldom performed
activities were left out and can be added after the same model. Optional steps
are marked by a decision block reflecting thus the questions a persona needs to
answer. They could be left out.
At least in
D365 the data can be imported over the Data Management Framework and/or the Excel
add-in. Some steps can then be consolidated or split depending on which data
entities are used, though the variations in process are small. Ideally, there
should be a description of the respective steps (e.g., what data entity applies for each step).
The process
doesn’t consider the use of an approval workflow, respectively the newest features.
One might
argue that the diagram doesn’t respect maybe some of the conventions existing
in Process Management. Some conventions make sense, though also in this area
one needs to compromise sometimes.
In what follows are given arguments why the various steps were considered.
Approve Product
datasheet
The data needed to create a Product usually comes from several departments (e.g. Sales, Procurement, Inventory Management, Engineering, etc.). Therefore, as for other master data, it’s recommended to have a Product datasheet in which the most important attributes about a product are tracked at the various levels of detail that apply.
This approach is supposed to fill the gap in the process in which the creation
of a product needs to be approved (e.g. somebody needs to confirm that there’s
an entitled reason) to eliminate the unnecessary creation of products (incl.
duplicates). Also, there are attributes like Name, Description, Unit of Measure
or Prices that need further agreement. Moreover, in this way a single persona
is responsible for process’ execution, and the approach requires more
coordination upfront than within the process. (It’s easier to have a call with
all stakeholders to complete the list than trying to involve them in the middle
of the process.)
The datasheet
should also contain the attributes that might require system’s extension with
further setup, and the new values should be marked as such.
Ideally, the
datasheet should reflect the data structure of the entities needed by the import
mechanism or allow easy conversions to them.
Setup
System
Setup
changes may reach deep inside several modules, requiring further permissions. Given
the sensitive nature of the changes, it’s better for these changes to be
performed by the people responsible for the respective areas.
Some changes,
including the hypothetical ones, might also require further tests. Therefore,
this part of the process should be triggered early enough so the delays are
kept to a minimum.
System’s
setup should be ideally documented (e.g. via golden configuration) together with
the policies that apply.
Create
Product(s)
The Product
datasheet will serve as basis for creating the Products during the current and
the following steps. The data entry should be just a replication of the data
from datasheet without further transformations, which tend to increase the chances
for mistakes.
Supposing
that D365 is the master system, which usually should be the case, the products
can also be created then in third-party systems once the Product number is
available, systems in which further restrictions, policies and value mappings may
apply.
Ideally,
there should be an automatic interface responsible for data synchronization,
otherwise manual effort is involved.
Add
language specific names/descriptions
Maintaining
both, a Product’s name and descriptions in the various supported languages should
be mandatory. The attributes should reflect the level of specificity required.
Assign Product
dimensions
The Product
sheet should reflect whether the Product requires dimensions, and which are the
respective values, respectively the combinations allowed.
Maintain Product categories
Categories’
maintenance is usually performed by other roles and belongs in the Setup System
process. This step includes the assignment of Products to a category,
respectively the maintenance of further attributes like Main account or Item
sales tax group.
Release
Product(s)
The
product(s) available in the datasheet are released to the Legal entities in
scope. This just makes the Products available for further maintenance.
Update
Released product(s)
The Product
datasheet is used as basis for entering the Legal entity-specific attributes.
Update
Default order settings
This step requires
updating the attributes that deviate from defaults (e.g. Default Site, Stopped,
etc.).
Maintain
Product ext. Descriptions
Product
external information might be needed for Customers and Vendors to which the
Products are sold, respectively from which are purchased. The entries are needed
for each Product dimension that applies.
Maintain
Trade agreements
Trade agreements
allow transparency of the Sales and Procurement prices that apply for a time
interval, specific group or other characteristics. Therefore, they should be
used when possible.
Maintain
Bar codes
Bar codes apply
usually for inventory-based products. Multiple bar code types may apply.
Validate
Product master data
This step
involves a review of the master data just entered, though it can involve an
interface to the ‘Monitor Master data’ process, when such a process was defined
as part of the Data Management or Governance initiative. The interfaced process
could be triggered as part of the initial process or as part of regular checks,
especially when the policies changed.
Typically,
the validation of the Product master data should be done by other persona after
the four-eyes principle.
Having a set of reports with all attributes in scope (aka ‘Product master data reports’) can easily pinpoint where the gaps are. Moreover, the ‘Product master data policies’ could be built within these reports however this is a long shot. If the policies are known, a simple review should be enough.
Correct
Product data
Besides troubleshooting, this step involves reviewing several or all the steps performed before and taking the necessary actions. Ideally, should be available a list of the most frequently met scenarios, respectively of fixes and workarounds.
Previous post <<||>> Next post
24 June 2020
Strategic Management: Simplicity I (Simple, but not that Simple)
 |
| Strategic Management Series |
Conversely, one talks about simplicity in IT without stating what is intended by it, and it can mean many things. Quite often the aim is packed within the ‘keep it simple stupid’ (aka KISS) mantra, a modern and pejorative alternative of Occam’s razor. KISS became a principle in software architecture design, and it can mean that a simple solution works better than a complex one, or that pursuing something in the simplest manner possible is usually better. The nuances are wide enough to cover a wide spectrum of solutions, arriving at statements that the simplest choice to make is the most appropriate one to make, thing that’s not necessarily true in IT, where complexity finds itself home.
Starting with the important number of technologies coexisting in integrations and ending with the exceptions existing in processes or the quality of data, things are almost never as simple as one may wish. An IT infrastructure’s complexity is dependent on the number of existing components, on whether they come from different generations or come from different vendor, on whether are deployed on different operating systems or are supported by different service providers, on the number of customizations made, on the degree of overlapping of the data and integrations needed to keep the data in synch, respectively of the differences existing in data models, quality and use. In general, the more variance, randomness, and challenges one has, the higher the overall complexity.
Paraphrasing Saint Exupéry, in IT simplicity is reached when there is no longer anything to add or anything to take away, or in Hans Hofmann’s words, simplicity is reflected in ‘the ability to simplify means to eliminate the unnecessary so that the necessary may speak’. This refers to the features, what a piece of software can do, respectively the functionality, how a certain outcome is reached, which arrive to be packed in various logical aggregations (function point, functional requirement, story, epic, model, product, etc.) or physical aggregations (classes, components, packages, services, models, etc.). These are the levels at which one needs to address simplicity adequately.
To make something simple one must be able either to design a solution up to the detail that there’s nothing to add or remove, or to start with something and remove or things to reach simplicity. Both approaches involve a considerable effort, time, and multiple iterations, however the first approach can easily become utopian as some architectures are so complex that sooner or later the second approach comes into play. Therefore, one needs in general to focus on what seems an optimal solution and optimize it continuously in further iterations. Aiming for perfection from the beginning or also later in the improvement process is a foolhardy wish.
Even if simplicity is hard to achieve, one can still talk about the elegance of a solution, scenarios in which the various components fit together like the pieces of a puzzle, or about robustness, reliability, correctness, maintainability, (re)usability, or learnability. These latter characteristics are known in Software Engineering as (software) quality attributes.
16 December 2019
IT: Technology (Just the Quotes)
"Systems engineering embraces every scientific and technical concept known, including economics, management, operations, maintenance, etc. It is the job of integrating an entire problem or problem to arrive at one overall answer, and the breaking down of this answer into defined units which are selected to function compatibly to achieve the specified objectives. [...] Instrument and control engineering is but one aspect of systems engineering - a vitally important and highly publicized aspect, because the ability to create automatic controls within overall systems has made it possible to achieve objectives never before attainable, While automatic controls are vital to systems which are to be controlled, every aspect of a system is essential. Systems engineering is unbiased, it demands only what is logically required. Control engineers have been the leaders in pulling together a systems approach in the various technologies." (Instrumentation Technology, 1957)
"Doing engineering is practicing the art of the organized forcing of technological change." (George Spencer-Brown, Electronics, Vol. 32 (47), 1959)
"The decision which achieves organization objectives must be both (1) technologically sound and (2) carried out by people. If we lose sight of the second requirement or if we assume naively that people can be made to carry out whatever decisions are technically soundwe run the risk of decreasing rather than increasing the effectiveness of the organization." (Douglas McGregor, "The Human Side of Enterprise", 1960)
"Any sufficiently advanced technology is indistinguishable from magic." (Arthur C Clarke, "Profiles of the Future: An Inquiry into the Limits of the Possible", 1962)
"Science is the reduction of the bewildering diversity of unique events to manageable uniformity within one of a number of symbol systems, and technology is the art of using these symbol systems so as to control and organize unique events. Scientific observation is always a viewing of things through the refracting medium of a symbol system, and technological praxis is always handling of things in ways that some symbol system has dictated. Education in science and technology is essentially education on the symbol level." (Aldous L Huxley, "Essay", Daedalus, 1962)
"Engineering is the art of skillful approximation; the practice of gamesmanship in the highest form. In the end it is a method broad enough to tame the unknown, a means of combing disciplined judgment with intuition, courage with responsibility, and scientific competence within the practical aspects of time, of cost, and of talent. This is the exciting view of modern-day engineering that a vigorous profession can insist be the theme for education and training of its youth. It is an outlook that generates its strength and its grandeur not in the discovery of facts but in their application; not in receiving, but in giving. It is an outlook that requires many tools of science and the ability to manipulate them intelligently In the end, it is a welding of theory and practice to build an early, strong, and useful result. Except as a valuable discipline of the mind, a formal education in technology is sterile until it is applied." (Ronald B Smith, "Professional Responsibility of Engineering", Mechanical Engineering Vol. 86 (1), 1964)
"It is a commonplace of modern technology that there is a high measure of certainty that problems have solutions before there is knowledge of how they are to be solved." (John K Galbraith, "The New Industrial State", 1967)
"In many ways, project management is similar to functional or traditional management. The project manager, however, may have to accomplish his ends through the efforts of individuals who are paid and promoted by someone else in the chain of command. The pacing factor in acquiring a new plant, in building a bridge, or in developing a new product is often not technology, but management. The technology to accomplish an ad hoc project may be in hand but cannot be put to proper use because the approach to the management is inadequate and unrealistic. Too often this failure can be attributed to an attempt to fit the project to an existing management organization, rather than molding the management to fit the needs of the project. The project manager, therefore, is somewhat of a maverick in the business world. No set pattern exists by which he can operate. His philosophy of management may depart radically from traditional theory." (David I Cleland & William R King, "Systems Analysis and Project Management", 1968)
"Technological invention and innovation are the business of engineering. They are embodied in engineering change." (Daniel V DeSimone & Hardy Cross, "Education for Innovation", 1968)
"Advanced technology required the collaboration of diverse professions and organizations, often with ambiguous or highly interdependent jurisdictions. In such situations, many of our highly touted rational management techniques break down; and new non-engineering approaches are necessary for the solution of these 'systems' problems." (Leonard R Sayles &Margaret K Chandler, "Managing Large Systems: The Large-Scale Approach", 1971)
"It follows from this that man's most urgent and pre-emptive need is maximally to utilize cybernetic science and computer technology within a general systems framework, to build a meta-systemic reality which is now only dimly envisaged. Intelligent and purposeful application of rapidly developing telecommunications and teleprocessing technology should make possible a degree of worldwide value consensus heretofore unrealizable." (Richard F Ericson, "Visions of Cybernetic Organizations", 1972)
"Technology can relieve the symptoms of a problem without affecting the underlying causes. Faith in technology as the ultimate solution to all problems can thus divert our attention from the most fundamental problem - the problem of growth in a finite system." (Donella A Meadows, "The Limits to Growth", 1972)
"Modern scientific principle has been drawn from the investigation of natural laws, technology has developed from the experience of doing, and the two have been combined by means of mathematical system to form what we call engineering." (George S Emmerson, "Engineering Education: A Social History", 1973)
"The system of nature, of which man is a part, tends to be self-balancing, self-adjusting, self-cleansing. Not so with technology." (Ernst F Schumacher, "Small is Beautiful", 1973)
"Above all, innovation is not invention. It is a term of economics rather than of technology. [...] The measure of innovation is the impact on the environment. [...] To manage innovation, a manager has to be at least literate with respect to the dynamics of innovation." (Peter F Drucker, "People and Performance", 1977)
"Numeracy has two facets-reading and writing, or extracting numerical information and presenting it. The skills of data presentation may at first seem ad hoc and judgmental, a matter of style rather than of technology, but certain aspects can be formalized into explicit rules, the equivalent of elementary syntax." (Andrew Ehrenberg, "Rudiments of Numeracy", Journal of Royal Statistical Society, 1977)
"Engineering or Technology is the making of things that did not previously exist, whereas science is the discovering of things that have long existed." (David Billington, "The Tower and the Bridge: The New Art of Structural Engineering", 1983)
"No matter how high or how excellent technology may be and how much capital may be accumulated, unless the group of human beings which comprise the enterprise works together toward one unified goal, the enterprise is sure to go down the path of decline." (Takashi Ishihara, Cherry Blossoms and Robotics, 1983)
"People’s views of the world, of themselves, of their own capabilities, and of the tasks that they are asked to perform, or topics they are asked to learn, depend heavily on the conceptualizations that they bring to the task. In interacting with the environment, with others, and with the artifacts of technology, people form internal, mental models of themselves and of the things with which they are interacting. These models provide predictive and explanatory power for understanding the interaction." (Donald A Norman, "Some observations on Mental Models", 1983)
"With the changes in technological complexity, especially in information technology, the leadership task has changed. Leadership in a networked organization is a fundamentally different thing from leadership in a traditional hierarchy." (Edgar Schein, "Organizational Culture and Leadership", 1985)
"[Computer and other technical managers] must become business managers or risk landing on the technological rubbish heap." (Jim Leeke, PC Week, 1987)
"Most managers are not capable of making decisions involving complex technological matters without help - lots of it. [...] The finest technical people on the job should have a dual role: doing technical work and advising management." (Philip W Metzger, "Managing Programming People", 1987)
"People don't want to understand all the components; they just want to make it [the technology] happen." (Bernadine Nicodemus, PC Week, 1987)
"The major problems of our work are not so much technological as sociological in nature. Most managers are willing to concede the idea that they’ve got more people worries than technical worries. But they seldom manage that way. They manage as though technology were their principal concern. They spend their time puzzling over the most convoluted and most interesting puzzles that their people will have to solve, almost as though they themselves were going to do the work rather than manage it. […] The main reason we tend to focus on the technical rather than the human side of the work is not because it’s more crucial, but because it’s easier to do."
"Information technology can capture and process data, and expert systems can to some extent supply knowledge, enabling people to make their own decisions. As the doers become self-managing and self-controlling, hierarchy - and the slowness and bureaucracy associated with it - disappears." (Michael M Hammer, "Reengineering Work: Don't Automate, Obliterate", Magazine, 1990) [source]
"The new information technologies can be seen to drive societies toward increasingly dynamic high-energy regions further and further from thermodynamical equilibrium, characterized by decreasing specific entropy and increasingly dense free-energy flows, accessed and processed by more and more complex social, economic, and political structures." (Ervin László, "Information Technology and Social Change: An Evolutionary Systems Analysis", Behavioral Science 37, 1992)
"Ignorance of science and technology is becoming the ultimate self-indulgent luxury." (Jeremy Bernstein, "Cranks, Quarks, and the Cosmos: Writings on Science", 1993)
"Technology is nothing. What’s important is that you have a faith in people, that they’re basically good and smart, and if you give them tools, they’ll do wonderful things with them." (Steve Jobs, Rolling Stone, 1994)
"Now that knowledge is taking the place of capital as the driving force in organizations worldwide, it is all too easy to confuse data with knowledge and information technology with information." (Peter Drucker, "Managing in a Time of Great Change", 1995)
"Commonly, the threats to strategy are seen to emanate from outside a company because of changes in technology or the behavior of competitors. Although external changes can be the problem, the greater threat to strategy often comes from within. A sound strategy is undermined by a misguided view of competition, by organizational failures, and, especially, by the desire to grow." (Michael E Porter, "What is Strategy?", Harvard Business Review, 1996)
"Management is a set of processes that can keep a complicated system of people and technology running smoothly. The most important aspects of management include planning, budgeting, organizing, staffing, controlling, and problem solving. Leadership is a set of processes that creates organizations in the first place or adapts them to significantly changing circumstances. Leadership defines what the future should look like, aligns people with that vision, and inspires them to make it happen despite the obstacles." (John P Kotter, "Leading Change", 1996)
"Networks constitute the new social morphology of our societies, and the diffusion of networking logic substantially modifies the operation and outcomes in processes of production, experience, power, and culture. While the networking form of social organization has existed in other times and spaces, the new information technology paradigm provides the material basis for its pervasive expansion throughout the entire social structure." (Manuel Castells, "The Rise of the Network Society", 1996)
"Issues of quality, timeliness and change are the conditions that are forcing us to face up to the issues of enterprise architecture. The precedent of all the older disciplines known today establishes the concept of architecture as central to the ability to produce quality and timely results and to manage change in complex products. Architecture is the cornerstone for containing enterprise frustration and leveraging technology innovations to fulfill the expectations of a viable and dynamic Information Age enterprise." (John Zachman, "Enterprise Architecture: The Issue of The Century", 1997)
"The Enterprise Architecture is the explicit description of the current and desired relationships among business and management process and information technology. It describes the 'target' situation which the agency wishes to create and maintain by managing its IT portfolio." (Franklin D Raines, 1997)
"All things being equal, choose technology that connects. […] This aspect of technology has increasing importance, at times overshadowing
such standbys as speed and price. If you are in doubt about what technology to
purchase, get the stuff that will connect the most widely, the most often, and
in the most ways. Avoid anything that resembles an island, no matter how well
endowed that island is."
"Beauty is more important in computing than anywhere else in technology because software is so complicated. Beauty is the ultimate defense against complexity." (David Gelernter, "Machine Beauty: Elegance And The Heart Of Technolog", 1998)
"Modelling techniques on powerful computers allow us to simulate the behaviour of complex systems without having to understand them. We can do with technology what we cannot do with science. […] The rise of powerful technology is not an unconditional blessing. We have to deal with what we do not understand, and that demands new ways of thinking."
"Technology is no panacea. It will never solve the ills or injustices of society. Technology can do only one thing for us - but it is an astonishing thing: Technology brings us an increase in opportunities." (Kevin Kelly, "New Rules for the New Economy: 10 radical strategies for a connected world", 1998)
"A primary reason that evolution - of life-forms or technology - speeds up is that it builds on its own increasing order." (Ray Kurzweil, "The Age of Spiritual Machines: When Computers Exceed Human Intelligence", 1999)
"As systems became more varied and more complex, we find that no single methodology suffices to deal with them. This is particularly true of what may be called information intelligent systems - systems which form the core of modern technology. To conceive, design, analyze and use such systems we frequently have to employ the totality of tools that are available. Among such tools are the techniques centered on fuzzy logic, neurocomputing, evolutionary computing, probabilistic computing and related methodologies. It is this conclusion that formed the genesis of the concept of soft computing." (Lotfi A Zadeh, "The Birth and Evolution of Fuzzy Logic: A personal perspective", 1999)
"Enterprise architecture is a family of related architecture components. This include information architecture, organization and business process architecture, and information technology architecture. Each consists of architectural representations, definitions of architecture entities, their relationships, and specification of function and purpose. Enterprise architecture guides the construction and development of business organizations and business processes, and the construction and development of supporting information systems." (Gordon B Davis, "The Blackwell encyclopedic dictionary of management information systems", 1999)
"Enterprise architecture is a holistic representation of all the components of the enterprise and the use of graphics and schemes are used to emphasize all parts of the enterprise, and how they are interrelated. [...] Enterprise architectures are used to deal with intra-organizational processes, interorganizational cooperation and coordination, and their shared use of information and information technologies. Business developments, such as outsourcing, partnership, alliances and Electronic Data Interchange, extend the need for architecture across company boundaries." (Gordon B Davis," The Blackwell encyclopedic dictionary of management information systems", 1999)
"Synergy occurs when organizational parts interact to produce a joint effect that is greater than the sum of the parts acting alone. As a result the organization may attain a special advantage with respect to cost, market power, technology, or employee." (Richard L Daft, "The Leadership Experience" 4th Ed., 2008)
"The butterfly effect demonstrates that complex dynamical systems are highly responsive and interconnected webs of feedback loops. It reminds us that we live in a highly interconnected world. Thus our actions within an organization can lead to a range of unpredicted responses and unexpected outcomes. This seriously calls into doubt the wisdom of believing that a major organizational change intervention will necessarily achieve its pre-planned and highly desired outcomes. Small changes in the social, technological, political, ecological or economic conditions can have major implications over time for organizations, communities, societies and even nations." (Elizabeth McMillan, "Complexity, Management and the Dynamics of Change: Challenges for practice", 2008)
"What’s next for technology and design? A lot less thinking about technology for technology’s sake, and a lot more thinking about design. Art humanizes technology and makes it understandable. Design is needed to make sense of information overload. It is why art and design will rise in importance during this century as we try to make sense of all the possibilities that digital technology now affords." (John Maeda, "Why Apple Leads the Way in Design", 2010)
"Enterprise Architecture presently appears to be a grossly misunderstood concept among management. It is NOT an Information Technology issue. It is an ENTERPRISE issue. It is likely perceived to be an Information Technology issue as opposed to a Management issue for two reasons: (1) Awareness of it tends to surface in the Enterprise through the Information Systems community. (2) Information Technology people seem to have the skills to do Enterprise Architecture if any Enterprise Architecture is being or is to be done." (John A Zachman, 2011)
"Today, technology has lowered the barrier for others to share their opinion about what we should be focusing on. It is not just information overload; it is opinion overload." (Greg McKeown, "Essentialism: The Disciplined Pursuit of Less", 2014)
"We have let ourselves become enchanted by big data only because we exoticize technology. We’re impressed with small feats accomplished by computers alone, but we ignore big achievements from complementarity because the human contribution makes them less uncanny. Watson, Deep Blue, and ever-better machine learning algorithms are cool. But the most valuable companies in the future won’t ask what problems can be solved with computers alone. Instead, they’ll ask: how can computers help humans solve hard problems?" (Peter Thiel & Blake Masters, "Zero to One: Notes on Startups, or How to Build the Future", 2014)
"Technological change is discontinuous and difficult. It is a radical change in that it forces people to deal with the world in a different way, that is, it changes the world of experience." (William Byers, "Deep Thinking: What Mathematics Can Teach Us About the Mind", 2015)
"The problem with artificial intelligence and information technology is that they promise a methodology that would lead to a way of solving all problems - a self-generating technology that would apply to all situations without the need for new human insights and leaps of creativity." (William Byers, "Deep Thinking: What Mathematics Can Teach Us About the Mind", 2015)
"Technology systems are difficult to wrangle. Our systems grow in accidental complexity and complication over time. Sometimes we can succumb to thinking that other people really hold the cards, that they have the puppet strings we don’t." (Eben Hewitt, "Technology Strategy Patterns: Architecture as strategy" 2nd Ed., 2019)
"Technology is not a magic pill that can solve inadequacies in processes." (Jared Lane, "Why Companies Should Stop Making Digital Transformation A Science Project", 2021) [source]
"Always remember what you originally wanted the system to accomplish. Having the latest, greatest system and a flashy data center to boot is not what data processing is supposed to be all about. It is supposed to help the bottom line, not hinder it." (Richard S Rubin)
"The first rule of any technology used in a business is that automation applied to an efficient operation will magnify the efficiency. The second is that automation applied to an inefficient operation will magnify the inefficiency." (Bill Gates)
14 December 2019
Governance: Control (Just the Quotes)
"To manage is to forecast and plan, to organize, to command, to coordinate and to control. To foresee and plan means examining the future and drawing up the plan of action. To organize means building up the dual structure, material and human, of the undertaking. To command means binding together, unifying and harmonizing all activity and effort. To control means seeing that everything occurs in conformity with established rule and expressed demand." (Henri Fayol, 1916)
"The concern of OR with finding an optimum decision, policy, or design is one of its essential characteristics. It does not seek merely to define a better solution to a problem than the one in use; it seeks the best solution... [It] can be characterized as the application of scientific methods, techniques, and tools to problems involving the operations of systems so as to provide those in control of the operations with optimum solutions to the problems." (C West Churchman et al, "Introduction to Operations Research", 1957)
"Management is a distinct process consisting of planning, organising, actuating and controlling; utilising in each both science and art, and followed in order to accomplish pre-determined objectives." (George R Terry, "Principles of Management", 1960)
"The term architecture is used here to describe the attributes of a system as seen by the programmer, i.e., the conceptual structure and functional behavior, as distinct from the organization of the data flow and controls, the logical design, and the physical implementation." (Gene Amdahl et al, "Architecture of the IBM System", IBM Journal of Research and Development. Vol 8 (2), 1964)
"If cybernetics is the science of control, management is the profession of control." (Anthony S Beer, "Decision and Control", 1966)
"Most of our beliefs about complex organizations follow from one or the other of two distinct strategies. The closed-system strategy seeks certainty by incorporating only those variables positively associated with goal achievement and subjecting them to a monolithic control network. The open-system strategy shifts attention from goal achievement to survival and incorporates uncertainty by recognizing organizational interdependence with environment. A newer tradition enables us to conceive of the organization as an open system, indeterminate and faced with uncertainty, but subject to criteria of rationality and hence needing certainty." (James D Thompson, "Organizations in Action", 1967)
"Policy-making, decision-taking, and control: These are the three functions of management that have intellectual content." (Anthony S Beer, "Management Science" , 1968)
"The management of a system has to deal with the generation of the plans for the system, i. e., consideration of all of the things we have discussed, the overall goals, the environment, the utilization of resources and the components. The management sets the component goals, allocates the resources, and controls the system performance." (C West Churchman, "The Systems Approach", 1968)
"One difficulty in developing a good [accounting] control system is that quantitative results will differ according to the accounting principles used, and accounting principles may change." (Ernest Dale, "Readings in Management", 1970)
"To be productive the individual has to have control, to a substantial extent, over the speed, rhythm, and attention spans with which he is working […] While work is, therefore, best laid out as uniform, working is best organized with a considerable degree of diversity. Working requires latitude to change speed, rhythm, and attention span fairly often. It requires fairly frequent changes in operating routines as well. What is good industrial engineering for work is exceedingly poor human engineering for the worker." (Peter F Drucker, "Management: Tasks, Responsibilities, Practices", 1973)
"A mature science, with respect to the matter of errors in variables, is not one that measures its variables without error, for this is impossible. It is, rather, a science which properly manages its errors, controlling their magnitudes and correctly calculating their implications for substantive conclusions." (Otis D Duncan, "Introduction to Structural Equation Models", 1975)
"Any observed statistical regularity will tend to collapse once pressure is placed upon it for control purposes." (Charles Goodhart, "Problems of Monetary Management: the U.K. Experience", 1975)
"When information is centralized and controlled, those who have it are extremely influential. Since information is [usually] localized in control subsystems, these subsystems have a great deal of organization influence." (Henry L Tosi & Stephen J Carroll, "Management", 1976)
"[...] when a variety of tasks have all to be performed in cooperation, synchronization, and communication, a business needs managers and a management. Otherwise, things go out of control; plans fail to turn into action; or, worse, different parts of the plans get going at different speeds, different times, and with different objectives and goals, and the favor of the 'boss' becomes more important than performance." (Peter F Drucker, "People and Performance", 1977)
"Uncontrolled variation is the enemy of quality." (W Edwards Deming, 1980)
"The key mission of contemporary management is to transcend the old models which limited the manager's role to that of controller, expert or morale booster. These roles do not produce the desired result of aligning the goals of the employees and the corporation. [...] These older models, vestiges of a bygone era, have served their function and must be replaced with a model of the manager as a developer of human resources." (Michael Durst, "Small Systems World", 1985)
"The outcome of any professional's effort depends on the ability to control working conditions." (Joseph A Raelin, "Clash of Cultures: Managers and Professionals", 1986)
"Executives have to start understanding that they have certain legal and ethical responsibilities for information under their control." (Jim Leeke, PC Week, 1987)
"Give up control even if it means the employees have to make some mistakes." (Frank Flores, Hispanic Business, 1987)
"In complex situations, we may rely too heavily on planning and forecasting and underestimate the importance of random factors in the environment. That reliance can also lead to delusions of control." (Hillel J Einhorn & Robin M. Hogarth, Harvard Business Review, 1987)
"Managers exist to plan, direct and control the project. Part of the way they control is to listen to and weigh advice. Once a decision is made, that's the way things should proceed until a new decision is reached. Erosion of management decisions by [support] people who always 'know better' undermines managers' credibility and can bring a project to grief." (Philip W Metzger, "Managing Programming People", 1987)
"To be effective, a manager must accept a decreasing degree of direct control." (Eric G Flamholtz & Yvonne Randal, "The Inner Game of Management", 1987)
"[Well-managed modern organizations] treat everyone as a source of creative input. What's most interesting is that they cannot be described as either democratically or autocratically managed. Their managers define the boundaries, and their people figure out the best way to do the job within those boundaries. The management style is an astonishing combination of direction and empowerment. They give up tight control in order to gain control over what counts: results." (Robert H Waterman, "The Renewal Factor", 1987)
"We have created trouble for ourselves in organizations by confusing control with order. This is no surprise, given that for most of its written history, leadership has been defined in terms of its control functions." (Margaret J Wheatley, "Leadership and the New Science: Discovering Order in a Chaotic World", 1992)
"Management is not founded on observation and experiment, but on a drive towards a set of outcomes. These aims are not altogether explicit; at one extreme they may amount to no more than an intention to preserve the status quo, at the other extreme they may embody an obsessional demand for power, profit or prestige. But the scientist's quest for insight, for understanding, for wanting to know what makes the system tick, rarely figures in the manager's motivation. Secondly, and therefore, management is not, even in intention, separable from its own intentions and desires: its policies express them. Thirdly, management is not normally aware of the conventional nature of its intellectual processes and control procedures. It is accustomed to confuse its conventions for recording information with truths-about-the-business, its subjective institutional languages for discussing the business with an objective language of fact and its models of reality with reality itself." (Stanford Beer, "Decision and Control", 1994)
"Without some element of governance from the top, bottom-up control will freeze when options are many. Without some element of leadership, the many at the bottom will be paralysed with choices." (Kevin Kelly, "Out of Control: The New Biology of Machines, Social Systems and the Economic World", 1995)
"Management is a set of processes that can keep a complicated system of people and technology running smoothly. The most important aspects of management include planning, budgeting, organizing, staffing, controlling, and problem solving." (John P Kotter, "Leading Change", 1996)
"The manager [...] is understood as one who observes the causal structure of an organization in order to be able to control it [...] This is taken to mean that the manager can choose the goals of the organization and design the systems or actions to realize those goals [...]. The possibility of so choosing goals and strategies relies on the predictability provided by the efficient and formative causal structure of the organization, as does the possibility of managers staying 'in control' of their organization's development. According to this perspective, organizations become what they are because of the choices made by their managers." (Ralph D Stacey et al, "Complexity and Management: Fad or Radical Challenge to Systems Thinking?", 2000)
"Success or failure of a project depends upon the ability of key personnel to have sufficient data for decision-making. Project management is often considered to be both an art and a science. It is an art because of the strong need for interpersonal skills, and the project planning and control forms attempt to convert part of the 'art' into a science." (Harold Kerzner, "Strategic Planning for Project Management using a Project Management Maturity Model", 2001)
"The premise here is that the hierarchy lines on the chart are also the only communication conduit. Information can flow only along the lines. [...] The hierarchy lines are paths of authority. When communication happens only over the hierarchy lines, that's a priori evidence that the managers are trying to hold on to all control. This is not only inefficient but an insult to the people underneath." (Tom DeMarco, "Slack: Getting Past Burnout, Busywork, and the Myth of Total Efficiency", 2001)
"Management can be defined as the attainment of organizational goals in an effective and efficient manner through planning, organizing, staffing, directing, and controlling organizational resources." (Richard L Daft, "The Leadership Experience" 4th Ed., 2008)
"In a complex society, individuals, organizations, and states require a high degree of confidence - even if it is misplaced - in the short-term future and a reasonable degree of confidence about the longer term. In its absence they could not commit themselves to decisions, investments, and policies. Like nudging the frame of a pinball machine to influence the path of the ball, we cope with the dilemma of uncertainty by doing what we can to make our expectations of the future self-fulfilling. We seek to control the social and physical worlds not only to make them more predictable but to reduce the likelihood of disruptive and damaging shocks (e.g., floods, epidemics, stock market crashes, foreign attacks). Our fallback strategy is denial." (Richard N Lebow, "Forbidden Fruit: Counterfactuals and International Relations", 2010)
"Almost by definition, one is rarely privileged to 'control' a disaster. Yet the activity somewhat loosely referred to by this term is a substantial portion of Management, perhaps the most important part. […] It is the business of a good Manager to ensure, by taking timely action in the real world, that scenarios of disaster remain securely in the realm of Fantasy."
"Without precise predictability, control is impotent and almost meaningless. In other words, the lesser the predictability, the harder the entity or system is to control, and vice versa. If our universe actually operated on linear causality, with no surprises, uncertainty, or abrupt changes, all future events would be absolutely predictable in a sort of waveless orderliness." (Lawrence K Samuels, "Defense of Chaos", 2013)
About Me
- Adrian
- IT Professional with more than 24 years experience in IT in the area of full life-cycle of Web/Desktop/Database Applications Development, Software Engineering, Consultancy, Data Management, Data Quality, Data Migrations, Reporting, ERP implementations & support, Team/Project/IT Management, etc.