Transforming the way of working is a goal on its own. At least that is my personal experiences.
I don´t believe that it is the intention, only not knowing better options to achieve change eliminating unsatisfying dillemma´s.
The one that is dropped first is: "Business"
There is a desire for simple fast solutions for the incomprehensible challenges needing a solution.
The circular walk through clockwise staring at bpm (Steer) this site by topics is broken at the edges.
Diagonal connections replaces the normal vertical Zachman lines.
When you are hitting this page (r-steer) from C-Know you followed that tempting path.
The negative sentiment for related organisational issues:
What: Ignore the organisation floor empowerment.
How: Bring in advisors with new technology .
Why: Hide in commodity approaches, hope for miracles.
Practising knowledge on technology
The positive approach for organisational issues:
Reuse existing commodity knowledge wisely
Reuse existing portfolio knowledgegement
Look for improvements with options in the commodity market
Avoid the known loopholes
Although the positive approach is the one that is needed for achieving results & goals, the threats and challenges are also needed to know.
The gap Business - ICT is mentioned, well known. The gap business strategy -theory vs running operations is overlooked.
Trying the Zachman vertical lines, many are found broken.
The White-collar Blue-collar gap revived in administrative/cyber, SWOT:
Reference
C-Steer (strategy - theory)
r-steer (practical executing)
B/P-*.1 Manage-ops
👁
Setting influence circle for missions missing: practical operations alignment
⇄
Quest for Servant leadership Quest: being centric for executing
B/P-*.2 service-ops
👁
focus to missions missing: practical operations alignment
⇄
running value streams, guidance gap 👉🏾ad hoc
B/P-*.3 compliancy
👁
Quest: regulations fulfilments but missing feedback control
⇄
❌ awareness for regulations without awareness no hope for service
B/P-*.4 service-val
👁
focus to visions, Hoshin Kanri missing: feedback closed loop
⇄
managing value streams, guidance gap 👉🏾ad hoc
B/P-*.5 reliability
👁
focus to hierarchy missing: technology compliancy
⇄
❓ doing as always has been done quest: technology embedded safety CIA
B/P-*.6 maturity
👁
The goals - kpi, okr to achieve
⇄
No influence on a given situation
Needed knowledge to read this
Basic knowledge:
Logic of Information processing for an organisation.
Basic understanding of computeres and their ICT technology.
Understanding what he impact of changing processes can be.
This page is the realisation area, there are refences to Jabes for enabling work.
Conversion started from 2020 content to align with new content Jabes.
2024 week:21
Draf version ready with all paragraphs.
Planning, to do:
Cleaning up old parts in Data data or meta moving into this location.
Refering to data paterns into new Data.
⚖ P-1.1.5 Jabes Relationship
The Jabes idea
Automating optimizing administrative work for enabling, servicing information processing.
Jabes Sponsor Stakeholder Supplier
A bottleneck for realisations is:
The real benefit is for organisations but:
Organisations don't have capabilities to recognize and do something about it.
Organisations (Steer) are suffering from the big gap between prudence policies (vision mission) and their own floor implementations (develop run, execute).
Consultancy for change, improve and innovation is the most logical Sponsor.
When changing the consultancy for change and innovation it will break their culture.
Technology, ICT, is will not build tools without: sponsor, stakeholders, supervising.
P-1.2 Question how to change?
Hierarchy in a pyramide.
Segregation in responsibilities in roles:
Strategy,
Tactics,
Operational
Working culture is set by the hierarchical top:
Hierarchy dictate details 👉🏾 micromanagement
Micromanagement 👉🏾 siloed organisations
Shared abstract goals. Siloed organisations 👉🏾 replacing for other goals
⚖ P-1.2.1 Lean thinking, lean planning
The real lean approach
The real lean approach is what is build up by Deming and all others by Toyoata, see:
A Brief History of Lean
It is much and overwhelming in details and relations. There are distractors falling back in old approaches.
The idea is coming back using other words, but not recognized it is the basically the same.
Design Thinking
What is Design Thinking? (Hasso Platner)
The Design Thinking process first defines the problem and then implements the solutions, always with the needs of the user demographic at the core of concept development.
This process focuses on needfinding, understanding, creating, thinking, and doing. At the core of this process is a bias towards action and creation: by creating and testing something, you can continue to learn and improve upon your initial ideas.
The design thinking process consists of these 5 steps:
EMPATHIZE: Work to fully understand the experience of the user for whom you are designing.
Do this through observation, interaction, and immersing yourself in their experiences.
DEFINE: Process and synthesize the findings from your empathy work in order to form a user point of view that you will address with your design.
IDEATE: Explore a wide variety of possible solutions through generating a large quantity of diverse possible solutions, allowing you to step beyond the obvious and explore a range of ideas.
PROTOTYPE: Transform your ideas into a physical form so that you can experience and interact with them and, in the process, learn and develop more empathy.
TEST: Try out high-resolution products and use observations and feedback to refine prototypes, learn more about the user, and refine your original point of view.
This was what promoted in 2020, in 2024 is changed
UNDERSTAND: Conducts research and collects relevant aspects of the project as well as general assumptions and knowledge to develop a collective perspective.
OBSERVE: analyze human-centered stories and anecdotes and summarizes the results in so-called “insights”.
DEFINE POINT VIEW: focuses on its most promising insights from the research phase and decides in what direction and for which user group it wants to develop solutions.
Agile Modeling (Scott Ambler)
What is Agile Modeling?
Agile Modeling (AM) is a practice-based methodology for effective modeling and documentation.
Some important concepts:
A model is an abstraction that expresses important aspects of a thing or concepts. Models may be visual (diagrams), non-visual (text descriptions), or executable (working code or equivalent). Models are sometimes called maps or roadmaps.
Agile model can be something as simple as stickies on a wall, sketches on a whiteboard, diagrams captured digitally via a drawing tool, or detailed models captured using a model-based software engineering (MBSE) tool.
Modeling is the act of creating a model. Modeling is sometimes called mapping.
Agile modeling is modeling performed in a collaborative and evolutionary manner.
A Document is a persistent representation of a thing or concept. A document is a model, but not all models are documents (most models are not persistent).
Agile documents can be something as simple as point-form notes, detailed text, executable tests, or one or more agile models.
Agile Modeling Documentation
If your goal is to have potentially shippable software every sprint as they say in Scrum, or better yet to have a potentially consumable solution every iteration as they say in Disciplined Agile (DA), then you will need to keep your deliverable documentation in sync with your software/solution – in other words, write deliverable documentation continuously throughout your initiative.
...
Furthermore, for the sake of discussion the term documentation includes both documents and comments in source code.
Regardless of what some people will tell you, documentation can in fact be quite effective.
When is a document agile? When it meets the following criteria:
Agile documents maximize stakeholder ROI. The benefit provided by an agile document is greater than the investment in its creation and maintenance, and ideally the investment made in that documentation was the best option available for those resources.
Stakeholders know the TCO of the document. Stakeholders must understand the total cost of ownership (TCO) of the document and be willing to invest in the creation and maintenance of that document.
Agile documents are “lean and sufficient”. An agile document contains just enough information to fulfill its purpose, in other words it is as simple as it can possibly be.
Agile documents fulfill a purpose. Agile documents are cohesive, they fulfill a single defined purpose.
Agile documents describe “good things to know”. Agile documents capture critical information, information that is not readily obvious such as design rationale, requirements, usage procedures, or operational procedures.
Agile documents have a specific customer and facilitate the work efforts of that customer.
System documentation is typically written for maintenance developers, providing an overview of the system’s architecture and potentially summarizing critical requirements and design decisions.
User documentation often includes tutorials for using a system written in language that your users understand whereas operations documentation describes how to run your system and is written in language that operations staff can understand. Different customers, different types of documents, and very likely different writing styles.
Agile documents are sufficiently accurate, consistent, and detailed. Agile documents do not need to be perfect, they just need to be good enough. .. The key issue being to identify how much ambiguity can the customers of the document accept and still be effective at their jobs.
Agile developers recognize that documentation is an intrinsic part of any system, the creation and maintenance of which is a “necessary evil” to some and an enjoyable task for others, an aspect of software development that can be made agile when you choose to do so.
There are several valid reasons to create documentation:
Your stakeholders require it. You will need to work closely with them to determine what they actually need, someone is going to have to decide to pay for the development and subsequent maintenance of the documentation, and you may even need to explain the implications of what is being requested, but this is doable.
To define a contract model. SContract models define how your system and an external one interacts with one another, some interactions are bi-directional whereas others are uni-directional, making the interaction(s) explicitly to everyone involved.
To support communication with an external group. shared documentation is often part of the solution in combination with occasional face-to-face discussions, teleconferencing, email, and collaborative tools.
To support organizational memory. One of the principles of Agile Modeling is Enabling the Next Effort is Your Secondary Goal which is meant as a counter-balance to the principle Working Software is Your Primary Goal. An important implication is that we not only need to develop software, but we also need to develop the supporting documentation required to use, operate, support, and maintain the software over time.
For audit purposes. Follow a defined process and capture proof, resulting in more documentation than normally written. ... Read the appropriate guidelines yourself, because they rarely require what the bureaucrats think they require.
To think something through. The act of writing, of putting your ideas down on paper, can help you to solidify them and discover problems with your thinking.
There is A market for management advice,
PMI talent triangle
The ideal skill set, the Talent Triangle, is a combination of technical, leadership, and strategic and business management expertise.
Update:
The sides of the PMI Talent Triangle now focus on:
Ways of Working: formerly Technical Project Management
Power Skills: formerly Leadership
Business Acumen: formerly Strategic and Business Management
An interesting part is:
PMI What Is Disciplined Agile?
Agile frameworks can be a good starting point, but they’re keeping many organizations from the improvement they expect. This is because business agility comes from freedom, not frameworks.
SDM - System Development Methodology
There is a long history of attempt to improve the way of working.
Cap Gemini SDM, or SDM2
is a software development method developed by the software company PANDATA in the Netherlands in 1970.
The method is a waterfall model divided in seven phases that have a clear start and end.
Each phase delivers (sub)products, called milestones.
The strict phases tempted to get strict bureaucratic control by management. This strict control resulted in use aversion.
The objective of project management
is to produce a complete project which complies with the client's objectives.
In many cases, the objective of project management is also to shape or reform the client's brief to feasibly address the client's objectives.
Once the client's objectives are established, they should influence all decisions made by other people involved in the project– for example, project managers, designers, contractors, and subcontractors. Ill-defined or too tightly prescribed project management objectives are detrimental to decision-making.
In a figure:
P-1.3 BPM: Process Life Cycle
Humans are aversive for change.
Negative sentiment:
Machines are taken over the world
Any failure or mistake: "Computer says no"
Dispose humans made obsolete by machines
Positive sentiment:
Machines 👉🏾 monotonously hard labour
Automatization 👉🏾 decrease failures, bias
Machines 👉🏾 help humans, support at complex hard comprehensible algorithms.
⟳ P-1.3.1 Processes - enterprise engineering
Demo valuable processing flow.
Process abstraction is a mindset with the goal to see similarities.
Call it demand/supply, Customer/Producer, requestor deliverer, there is a circle in the process. demo 2016 handout presentation.
The producer is the one that is an contact with the customer / requestor.
In a figure:
Confusing: ❶ product delivery is right to left. ❷ O-phase 👉🏾 Pull. ❸ R-phase 👉🏾 Push. ❹ No clear PDCA cyle.
Processes, transactions oriënted.
Product lifecycle (wikipedia)
In industry, product lifecycle management (PLM) is the process of managing the entire lifecycle of a product from inception, through engineering design and manufacture, to service and disposal of manufactured products.
PLM integrates people, data, processes and business systems and provides a product information backbone for companies and their extended enterprise.
❶ Question:
❓ Why should PLM be reserved only for industry of physical artefacts ❓
Answer:
😉 Use the same approach for the administrative/cyber products❗ ❷ Question:
🤔 There is: Top-Down, Bottom-up, Both-Ends-Against-Middle, where Middle-Against-Both-Ends (MABE) ❓
Answer:
😉 IT is in the middle the context switch for functionality and technology happens.
Details and abstractions to both ends are at both ends increasing❗
The value stream - flow similar to a factory
An organisation has four phases in activities.
These are:
IV - 0,1 a customer wit a demand / request / desired result
III - 3 promise for a delivery, planning preparing needed input - materials
I - 4,5 retrieving input a materials, producing the product
II - 6,9 verifying the product and handing the result over to the customer
There are decision in this cycle, those are:
2 is it possible or wanted to fullfill the demand / request wiht all conditions?
7 partial validations for the intended quality of the product
8 holostic validation for the intended quality of the product
In a figure:
A lot is combined in this figure, these are:
Product flow, values stream is shown left to right
The processing cycle is clockwise
Push: delivery left to right at the top
Pull: Plan prepare enable right to left at the bottom
The customer is coming and leaving at the bottom right side. 0,9
The customer is only seeing the front end customer desk.
High level strategy management is in the middle, control at the bottom, at the top the transformation / manufacturing .
Managing controlling the cycle is centralised in the centre.
⟳ P-1.3.2 Processes - engineering control managing
Processes, transactions oriënted.
(Demo pub) 2015-07-17 Dietz, Jan L.G. - Concise Summary of DEMO-3
Focussing on the process with actions and their flow. This is very detailed on what is happening and whether that is what is required for the organisation by decompositions.
The theory that underlies the notion of enterprise ontology as presented by Dietz is called the-theory.
Design & Engineering Methodology for Organizations
DEMO assumes that an organization consists of three integrated layers:
B-organization: Essential, business system or the B system
I-organization: Informational, either the information I system
D-organization: Documenteel, data system either D system
The main focus in DEMO is focused on the critical level, the other two are, therefore, less discussed in detail.
In a figure:
Just reversing the shape of triangle keeping the the colours similar.
Assuming the enterprise transactions to produce are all in the now biggest red part of the triangle.
The other colours - layers, have several options (multiple dimensions). The option for using layered coordination is the one that is a fit when a management information system is the question.
Replacing the noisy details in the previous figure with four phases in a circle results in a more abstract version.
Each triangle is representing one of the four phase of the product value stream.
B-organization: Operational
I-organization: Tactical informational
D-organization: Strategy decisions
The internal product flow and organisational silos are clearly visible.
A lot of areas where gaps and miscommunications are to be found.
⟳ P-1.3.3 Value Streams - Control management
Inventory one of the options - Levelling (Heijunka)
❶ Question: What is limiting efficiency ❓
Answer: 😉 What is not visible is the external product flow and how to solve fluctuations in customer demand.
The Three Fundamental Ways to Decouple Fluctuations
Generally, the less fluctuations you have, the more efficiently you can be. Three basic ways how you can decouple fluctuations: inventory, capacity, and time.
Inventory one of the options - Levelling (Heijunka)
The value stream with all transformations and interactions is not that predictable.
Why Levelling (Heijunka) is important
With the different sources of fluctuations, it is important to realize that they are connected.
You receive the fluctuations from your customer.
You also receive fluctuations from your supplier. However, you are the customer of your supplier, and they also receive fluctuations from you!
Hence the fluctuations on your shop floor are not only a result of others, but also by itself a source of fluctuation.
⌛ Using inventory is probably the easiest way to have a structured decoupling of fluctuations.
You can add it pretty much between every process to buffer the fluctuations between the processes. ⏳ Another way to decouple fluctuation is by adjusting your capacity. -
The problem with adjusting capacity is the delay between the decision to increase or reduce capacity, and the actual increased or reduced capacity. 💰 If you didn’t manage to decouple using buffer or capacity, eventually somebody has to wait.
Solving fluctations, waits:
Structure for Reducing Fluctuations
However, please note that due to the large number of possible reasons for fluctuations, this guide is only a rough outline. There are still plenty of things for you to analyze and decide on.
⟳ P-1.3.4 Abstraction figures process models
The proces life cycle
Mindset prerequisites: Siar model - static
The model covers all of:
simple processes: 0 - 9
The duality between processes, transformations, and information, data
four quadrants:
Push Pull,
lean agile requests deliveries
realistic human interaction & communication. nine plane:
Steer Shape Serve
Strategy, Tactics, Operational
Accountabilities, responsibilities, roles
Less obvious ohers:
value stream: left to right
PDCA, DMAIC, lean agile improvements
The mindset by this model is used over and over again.
Mindset prerequisites: Siar model - dynamic
The cubicle representation of the model did show a lot.
The static element information is well to place.
Processing, transforming, is a dynamic process.
A circular representation is a better fit.
The cycle:
Ideate - Asses
Plan - Enable
Demand, Backend
Frontend , Delivery
Customer interaction: bottom right side.
Supply chain interaction: bottom left side.
P-1.4 BPM: Value stream simplistic
There is a long history for executing processes.
What are the steps in a value stream? Wat is to be done?
Ideate Asses - Plan Enable 🎭 These are pull actions
Demand / push: 👉🏾 Prepare, validate information input
Process / push: 👉🏾 Transform conform instructions
Deliver / push: 👉🏾 Validate results before handing over
🎭 P-1.4.1 Managing Poduct flows using processes
Not recognized 😱 being important
One would assume the working force for delivering the product servicing the product being seen as key assets for the product line.
Strange enough this assumption is not true.
A very normal seen situation:
Workers being classified: easily replaced by others, for lower cost.
Servicing a product is easily seen as something to be outsourced to other parties without further attention.
Examples are:
A third party call center for solving questions for a product.
A robot that does questions and answers for a product.
The questionaire by a third party For quality experiences on the service.
❓ Question: How would known issues getting solved, unknown issues being escalated to become known ones?
There is a complete framework for information technology: ITIL.
I have never seen Itil got success by supporting product lines it is a technology driven approach.
( to be continued - see role)
Product Management is not Project Management although they have both the letters PM.
The process flow
❶
A Value stream
is the set of actions that take place to add value to a customer from the initial request through realization of value by the customer.
The value stream begins with the initial concept, moves through various stages of development and on through delivery and support.
A value stream always begins and ends with a customer. Value stream is usually aligned with company processes. ❷
Value streams are artifacts within business architecture that allow a business to specify the value proposition derived by an external (e.g., customer) or internal stakeholder from an organization.
A value stream depicts the stakeholders initiating and involved in the value stream, the stages that create specific value items, and the value proposition derived from the value stream.
he value stream is depicted as an end-to-end collection of value-adding activities that create an overall result for a customer, stakeholder, or end-user.
...
🎭 P-1.4.2 Business processes modelling
⚒ Physical:
Out of scope.
Business valuse stream scope
copied from: A-2.3.2 Business processes modelling.
From: "Want to do a process mining project" slides and videos (vdaalst).
VSM, process mining, processes data
The idea of using data, transformed into information for seeing what is going on the shop floor is based on what information is avaliable.
The dependency of what common commercial tools are by default offering is the limatation and unnecessary complexity.
Well known commercials:
SAP, Oracle, Microsoft, Broadcom
ServiceNow, Saleforce, Informatica
Open-text, Mico focus, Hp service center
In a figure:
See right side
VSM, process mining, processes stream
A process stream is a simple flow of basic processing steps.
Not all process events will follow the expectation from the VSM map design.
In the example (Source: WvAalst) the usual order is:
place order
send invoice
pay
prepare delivery
make delivery
conform payment
The there are cases not following that order or there execpetations in the duration. That should give questions to solve, questions whether improvements are possible or even necessary.
In a figure:
See right side
🎭 P-1.4.3 Process cycle: Data model, Architect: value stream
Obligations
To get covered in knowledge by a portfolio:
why:
Input: value stream of the product.
The input can be seen as an extract from some source.
Result: value stream of the product
The result can be seen as a load to some destination.
Process: One or more transformations in the stream to build the product.
Note: the revival of "ETL" at high level. The ELT is seen in transformations.
Consequences of functional accountabilities (what)
Impact to organisational accountabilities (who)
In a figure:
See right side.
Cooperation
All the necessary knowledge is impossible to fulfil by a single person.
Cooperation is communicating with other persons.
In an incremental process:
Input: What is the existing or expected information quality
Result: What is the required expected information quality
Who are accountable for the input information
Who will be accountable for the information results
What are existing transformation options
What are alternative transformation options
The whole of the new process is in scope for this. It is future promised outcome, expectations.
🎭 P-1.4.4 Data model, Architect: functional accountabilities
⚖ Obligations
It is not only blindly following instructions managing the product process flow.
The value stream has mandatory requirements to be fulfilled to be shown for the products in the portfolio.
During design and validation of the product they should get materialized.
As long the product is relevant, that is customers are using it or are able to refer it, the information of the portfolio product for dedicated version should be at least retrievable.
To get covered by information knowledge by a portfolio:
Security architecture (technical)
Operational risk (functional)
Privacy - impact
Process - impact
In a figure:
See right side.
⚙ Cooperation
All the necessary knowledge is impossible to fulfil by a single person.
Cooperation is communicating with other persons. The communiction is by hierarchy line and by capabilites lines.
In an incremental process:
Shared understanding of the direction
There is, or should be, a "e Hoshin Kanri"e or X-matrix.
That is clear statement on what the vision on fucntional missions are.
Shared information of work in progress
Review of the design incrementals
The earlier issues are recongized the better faster and cheaper corrections are.
Correction or remarks on review results
The earlier issues are recongized the better faster and cheaper corrections are.
This is a process in his own with the goal of only going that far in details others can start their work while covering at least known mandatory requirements.
⚒ Compliancy artifacts Accountability
❷ Information quality (functional / technical ) is to be solved in cooperation with dedicated specialists.
The lead for doing that at those side. ❸ Explainable PII usage (functional / technical ) is to be solved in cooperation with dedicated specialists.
The lead for doing that at those side. ❹ Explainable Algorithms is to be solved in cooperation with dedicated specialists part of missions (C-Steer).
The lead for doing that at those side. ❶ Information Security for the service and having a portfolio for services is within the operational scope when change and support is also in scope.
The lead for doing that in scope for responsibility of the practical organisation where accountability is a the strategic organisation.
P-1.5 Serve: (Information) Technology
Product data management (PDM) is focused on capturing and maintaining information on products and/or services through their development and useful life.
Change management is an important part of PDM/PLM.
⚒ Physical:
Out of scope.
⚖ Legal:
Contracts, negotations are left out of scope although important.
🎭 P-1.5.1 The Product Management role
Not recognized 😱 being important
One would assume the working force for delivering the product servicing the product being seen as key assets for the product line.
Strange enough this assumption is not true.
A very normal seen situation:
(continuation from flows)
Improving a productline on the other hand, gets a lot of attention but lacking the real why's for the improvements.
What I am indicating are the hypes and focus one:
Changes for using the latest new programming languages.
Becoming datadriving while the core product processes are not understood.
Going for new technology while the core product processes are not understood.
❓ Question: How would the core product process be in quality continuity and cost with all this kind of uncertainties?
I have seldom seen accountable management being committed to product lines it moved to they are only getting involved.
The Chicken and the Pig
For a Scrum project the Development Team, Product Owners & Scrum Masters are considered as people who are committed to the project while stakeholders, customers and executive management are considered as involved but not committed to the project.
As of 2011, the fable has been removed from the official Scrum framework.
Product Management is not Project Mangement although they have both the letters PM.
The proces life cycle 👁
Going back to the basics where product management is the key player. Going into the core processes, value streams. ❶ Product management
is the process of planning, developing, launching, and managing a product or service.
It includes the entire lifecycle of a product, from ideation to development to go to market.
Product managers are responsible for ensuring that a product meets the needs of its target market and contributes to the business strategy, while managing a product or products at all stages of the product lifecycle.
... ❷
Product managers are responsible for managing a company's product line on a day-to-day basis. As a result, product managers are critical in both driving a company's growth, margins, and revenue. They are responsible for the business case, conceptualizing, planning, product development, product marketing, and delivering products to their target market.
... ❸
Product managers analyze information including customer research, competitive intelligence, industry analysis, trends, economic signals, and competitive activity, as well as documenting requirements, setting product strategy, and creating the roadmap.
Product managers align across departments within their company including product design and development, marketing, sales, customer support, and legal.
...
The holistic approach for Product management the full circle of the SIAR model, static & dynamic.
The product is part of a portfolio having specifications. How the product is created is set by requirements.
What are the steps in a value stream? Wat is to be done?
IV Ideate - Asses / pull : 🎭 These are interactions with the customer
Advice in options, Align customer - Monitor requests
III Enable - Plan / pull: 📚 Prepare, validate information input
Continuity & support- solve known issues, Escalate unknowns
I Demand - Backend / push: ⟳ Transform conform instructions
Service evaluation - Demand
II Frontend - Delivery/ push: 👉🏾 Validate results before handing over
Delivery - Customer after Care
In a figure:
See right side
🎭 P-1.5.2 A tool supporting Product management
A toolset that is missing in administrative/cyber world
❓ Question what is missing aside the previous mentioned issues?
How about a portfolio management system:
Describing specifications of the products and how they should be used
Having the requirements from what the products are build
Supporting in instructions for how the products are build
Copied from:
Y-2.2.1 Change initiation
A-2.5.1 PDCA cycle administrative support
A toolset for the portfolio (static executing)
Jabes a proposal for the administrative/cyber product processes.
The meta model conforms to the layers in the nine-plane with some differences.
The information stores on processes have all three layers aligned to hierarchy and a topc.
The main information constructs: ❶ The suggestion box, backlog, known issues, innovation proposals (down left)
❷ design & building the process or components (top left)
❸ validations of the process the process, is at the II (top right)
❹ the specifications with, known issues, is at the IV (down right)
A figure:
See left side
Agile value stream changes - execute
The product validations are consolidates into product specfications.
Validations are repeatable to deliver proof of the specfications.
Having the requirements from what the products are build.
Supporting in instuctions for how the products are build
Once a change has been started there is continuous activity for "design/build" and "product validation".
This stops at the moment the enablement is blocked or the new specifications are accepted to be of high quality where no need for change is requested.
🎭 P-1.5.3 Supporting Product management Projects
A toolset that is missing in administrative/cyber world
❓ Question what is missing when there is a goode description of the portfolio?
How about changing content in the portfolio management system:
Changing specifications of the products and how they should be used
Changing requirements from what the products are build
Changing instructions for how the products are build
A tool for the portfolio (dynamic change)
For every activity there is a planning and logging control dataset.
There are already a lot of tools in the market but there is no share managed data information system.
The goal is to use this shared consolidated portfolio information system.
Managing updates content wiht monitoring and logging: ❶ suggestion box, backlog, known issues, innovation proposals (down left)
❷ design & building the process or components (top left)
❸ validations of the process the process, is at the II (top right)
❹ the specifications with, known issues, is at the IV (down right)
A figure:
See left side
🎭 P-1.5.4 Wish: Data driven processes
⚒ Managing changess
Knowing how the change process is evolving for what is done and what is planned is important information for feed-back.
Registration actions, documenting progress is a requirement to do underpinned analyses and reporting. ❶ Knowing the backlog, ideas and suggestions
💡 This collection is important input for:
decisions what is possible
what is needed
what is possible
❷ Monitoring the design process
🚧 Any design is not possible in a single cycle, many cycles will be needed. ❸ Monitoring the validation process
🚧 Any validation can be designed during product design and many should be easily repeatable. ❹ Planning - Monitoring the release of updated & new products
🎯 Achieving a goal goes along with validating and evaluating what has been done.
⚒ Using Jabes metadata context scopes
A values stream is a realisations of a service.
A stream is build up by several steps each using tools platforms with engineered construction.
The technical construction of a service is somehow different to the fucntional usage of the service.
❗ Recent regulationse are setting obligations to functional services (Nis2 Dora).
For Jabes there need to be metadata context split of:
Portfolio technical build of the service
Portfolio functional service properties
P-1.6 Maturity 3: fundaments processes
"Managing technology service" is a prerequisite for "processes: cyber/adminstrative".
Although the focus should be on the value stream processes it starts by the technology connection.
From the three PTO, BPM interrelated scopes:
❌ P - Processes: cyber/adminstrative
✅ T - Managing technology service
❌ O - Organization optimization
⚖ P-1.6.1 Floor Impediments
Shop floor supervisor
Being in a role at floor there not really easy ways to get out of situations that are hampering and blocking the work to be done.
🤔 The hope for improvements is a route by Gemba (Shape).
In the following sections are common normal issues requiring attention.
They are too often the root causes for not achieving real progress.
⚖ P-1.6.2 Organisation of work
🤔 Shop floor supervisor
Looking for who is doing and organising the work at the Shop-floor.
All attention is going to other topics:
creating software
New interesting technology
What big tech advisors are saying
Better being good at is knowing and understanding the own organisation.
The "C-Steer" chapter is: B-3.2.2. 💣 Need having solved: Shop Floor accountabilities.
👁 First line, second line supervisors
Looking for the cyber/administrative physical equivalent of who accountable for the value stream flow.
The hierarchical implementation is easily missed. These equivalent is missing. The awareness of a values stream is also missing. Training Within Industry—Second-Line Supervisor Job Instructions
Training Within Industry and its modules Job Instructions, Job Relations, and Job Methods are well known. ...
Job Instructions for Second-Line Supervisors (nowadays called managers).
This is a hierarchy level higher, and the goal is to support and guide the shop floor supervisors on how to use job instructions.
The point-of-use provider takes care of the "last mile" (or more precisely last few meters) of the material transport.
This is often for assembly lines, as there is a lot of material arriving.
⚒ P-1.6.3 Understanding information "Cyber/administrative"
🤔 Understanding & cooperating Technology
Looking for who is doing and organising the work at the Shop-floor.
All attention is going to other topics:
creating software
New interesting technology
What big tech advisors are saying
Better being good at is knowing and understanding the own organisation.
The "C-Shape" chapter is: A-3.3.2. 💣 Need having solved: Shared glossary with cooperation.
Context confusing: business - cyber technology
There is a lot of misunderstanding between normal humans and their cyber colleagues.
That culture is not necessary, should be eliminated. A translation of words to start:
ICT
Business
ICT
Business
ICT
Business
Strategy
Control
-
Functional
Target-Value
-
Confidentiality
People
Tactical
Orchestration
-
Compliancy
Communication
-
Integrity
Processes
Operational
Realization
-
Technical
Information
-
Availability
Machines
Note that the asset "Information" is a business asset not something to be pushed off as something incomprehensible "cyber".
A figure:
See right side
⚙ P-1.6.4 Security processes - Identities access
🤔 Understanding & cooperating Technology
Looking for who is doing and organising the work at the Shop-floor.
All attention is going to other topics:
creating software
New interesting technology
What big tech advisors are saying
Better being good at is knowing and understanding the own organisation.
The "C-Serve" chapter is: T-2.5.3. 💣 Need having solved: Responsibility for clear security.
generic securyt access
There is a "Devil´s Triangle" on its own wiht IAM. Conflicting types of interest:
Giving granting access to humans. Conforming the hierarchical organisation structure.
Securing technical systems, the supply chain included. Conforming.
Design secure Platforms, secure organisational business information processes.
A figure:
See right side
Who is the CSO?
Security of the assets owned by the organisation is too often seen as something technical.
💣 Actions by the ICT department pretending to be in security control
⚒ Make the business responsible for the security guideline. See ICT staff as enablers data processor not as data controller (GDPR)
⚙ P.1.6.5 Business processes Administrative/cyber
🤔 Understanding & manging processes
Looking for who is doing and organising the work at the Shop-floor.
All attention is going to other topics:
creating software
New interesting technology
What big tech advisors are saying
Better being good at is knowing and understanding the own organisation.
The "C-Shape" chapter is: A-2.3.3. 💣 Need having solved: Responsibility for managing processes.
Data driven - process driven
There is strong relationship between two approaches, data-driven, process-driven they can´t exist without the other.
fluxicon disco manual (vdaalst)
Data science is the profession of the future. However, it is not sufficient to focus on data storage and data analysis.
The data scientist also needs to relate data to processes.
At the same time, process analysis professionals need to learn how to incorporate data from the IT systems into their work.
Assumed processes - reality:
When you ask someone about how their process is being performed, or look how it is documented, the structure is typically relatively simple (“First we do X, then, we do Y, etc.”).
However, in reality processes are much more complex.
👉🏾 There is rework: Steps have to be done again, because they were not right the first time.
👉🏾 Exceptions need to made to deal with special situations, different people perform the same process in different ways, and so on.
👉🏾 So, there is a discrepancy between how people assume that processes are performed and how they are actually executed.
... But looking further, this discrepancy is not even the biggest problem.
After all, to a certain extent it can be expected that not everything is always going according to plan.
💣 The much bigger problem is that in most situations nobody has an overview about how the real process looks like in the first place.
In a figure:
See left side
Why is it so difficult to have an overview about how the processes are actually performed?
Subjectivity: Everyone has a subjective picture of the process.
Partial view: Specifically for processes there is the additional challenge that there is not one single person that performs the complete process.
Change: Processes change all the time, often while they are being analysed.
Invisibility through digitization of processes. In the old times, a pile of paper on the desk was an indication.
Nowadays a customer case can stuck in the system only hearing about it once the customer complains.
⚖ P.1.6.6 Short checklist floor impediments
Need having solved:
❌ ✅ Shop Floor accountabilities.
❌ ✅ Shared glossary with cooperation for technology
❌ ✅ Responsibility for clear security at the shop floor.
❌ ✅ Responsibility for managing processes at the shop floor.
These are to be understood solved and managed by management at the high levels. This can be measured by maturity metrics.
The usual situation is: none of them is in place. Worse, there is even no awareness, CMM level-0.
The organisation structure is a hierarchical line of command. Group formations using leaders is human nature.
⚠ Challenges: avoiding leadership to micro details, bad goals.
A swarm organisation, self organisation, are networked structures without leaderships. Using some shared goal.
⚠ Challenges: have a shared goal, have a good shared goal.
👁 P-2.1.1 Mindset for divide & conquer work
The process Life Cycle
The hierarchical approach with:
Strategy, Tactics, Operations
Shop floor focus on development of:
DS Analytics - applications including business intelligence artificial intellignce.
ICT Analytics - Development of platforms tools enabling applications (devops).
Add the PDCA cycle for OKR, Objective Key Results:assess / ideate, develop, deploy, run.
These involved parties are expected to cooperate well for achieving mission goals.
In a figure:
Failing by accountability responsibility
❓ Question: When is shared technical interest is data management, what is the best solutions for a hierarchical single line of control?
The problem for data information processing:
DS Analytics - dependant of organisation missions and business regulations, compliancy
ICT Analytics - dependant of organisation missions and ICT regulations, compliancy
What happens when there is no single line of control?
To understand, position the activities & roles in a quadrant figure :
I - standard supported operations.
II - Organisational missions to achieve by stakeholders managers executives.
III - the place of nothing, no support no interest.
"Shadow IT", Incubation, one-off
Note the difference ❗ For the SIAR model it is: Plan, Enable.
IV - Research, Innovation, Design.
Put in:
I - ICT tools (generic - operating system), DW support.
II - Turn the pyramid 45 degrees clockwise so it will fit into the quadrant.
Departments for the best fit location according connected quadrants.
III - Research, Innovation, Design.
IV - DS Analytics, ICT Analytics
In the middle of the quadrant there is the "wall of confusion".
The figure:
Innovation, research threats
Wat are the threats, risks:
Getting request done and fullfilled by: DS Analytics, ICT Analytics.
Data, information Amp tools retrieved by analtyics teams.
Work of teams getting blocked by DW support, ICT tools.
What could bring value is dumped.
Getting Data, information & tools DW support, ICT tools.
Data, information & tools dictated by hierarchy to analtyics teams.
There is in reality no value for DS Analytics, ICT Analytics, dumped.
There many more ways to do it incorrect than to do it correct.
👁 P-2.1.2 Details Failing by accountability responsibility
Getting Data DS analytics - DW support
The =DW support= is managing data central using DBMS systems.
Issue: a clear proces having a single direct line in control is lacking.
Pitfalls neglecting =ICT Analytics=:
Bad performance or even unworkable operationable processings.
Not being aligned with business properties and/or legal requirements.
Not suited for future changes by a technology lock-in.
in a figure:
Getting Data IC Analtyics- DW support
A direct request from =ICT Analytics= to =DW support= is neglecting =DS Analytics=
Issue: Handing over accountablity will fail by lack of involvment.
Pitfalls neglecting =DS Analytics=:
Wrong data,information being retreived.
Data, Information not in a state being needed, expected.
Timing of delivery data, information not as needed.
Model building and scoring have differences in requirements.
in a figure:
Requesting tools DS analytics - ICT Tools
In this case =ICT Tools= managing servers and "the applications" (tools)
A clear proces having a single direct line in control is lacking.
Issue: a clear proces having a single direct line in control is lacking.
Pitfalls neglecting =ICT Analytics=:
Unnecessary steps by crossing machine layers causing difficulties in data representation (encoding transcoding).
Even not able to proces what has developed operationally.
An one-off once analyse report dashboard is different to one that should be embbeded into to business operations.
Not being aligned with generic business policies (eg security) and legal requirements.
Not suited for future changes by a technology lock-in.
in a figure:
Requesting tools ICT analytics - ICT Tools
A direct request from =IC Analytics= to =ICT tools= is
Pitfalls neglecting =Ds Analytics=:
The requested state of the art tools as expectation is a mismatch.
The delivery getting blocked for not clear reasons.
in a figure:
P-2.2 Missions into processes
A swarm organisation, self organisation, are networked structures without leaderships. Using some shared goal.
⚠ Challenges: have a shared goal, have a good shared goal.
The organisation structure is a hierarchical line of command. Group formations using leaders is human nature.
⚠ Challenges: avoiding leadership to micro details, bad goals.
⚒ P-2.2.1 Operational flow, value stream
Warehousing - Logistics
Every process line has a moment of:
request, materials, components coming in
delivery, product going out
A data warehouse should be central of any information system, the operational system.
Lean is not about eliminating the warehouse, minmizing waste.
Non shared flow, Shared flow
In administrative/cyber we have not the physical limitations that are most important ones.
❓ Question: How to organize the Datawarehouse? Line Layout Strategies – Part 1: The Big Picture ❶ Shared:
For systems where the inbound and outbound warehouse is combined.
In this case, a “loop” starting and ending near the warehouse would be best.
Advantages Administration/Cyber:
Minimizes the number of components (DBMS).
Disadvantages Administration/Cyber:
Sharing of resources.
Note: No need for a single centralize warehouse.
❷ Non-Shared:
A good line design would follow the overall material flow and go from the left to the right.
Administration/Cyber Advantages:
If made, follows the busisess model.
clear roles responsibilities.
Easy to understand and implement for safety, security.
Overall, this debugging process will also help you with the "check" and "act" of the PDCA sequence.
If you do this debugging, you will learn if the system actually works and if it is (hopefully) better than what you had before.
Don´t take it for granted that just because you changed something, it must be better than before!
Transport in manufacturing.
Processing objects, information data is usually crossing many applications systems.
This involves data transport data conversions and will require data validation.
There are different types of kanban. Most often you distinguish between a production kanban and a transport kanban (withdrawal kanban).
A production kanban issues the reproduction of a new part. A transport kanban merely orders another part from a preceding supermarket or general inventory.
Any kind of transport that can be avoided of collected to be minimal will result in a lean process.
⚒ P-2.2.1 Changing flow, value stream
Becoming data driven
There is a long history for building and deploying changes, the classic way of coding ALC-V2 and AlC-V3.
The AlC-V3 is associated with crisp-dm.
Presidion crisp-dm is showing this more advanced picture.
Notes for the figure:
There is "monitoring" after deployment.
Deployment is not part of process cycle, no PDCA.
In the official Crisp-dm the monitoring phase is missing.
Aside the monitoring a lot more is missing.
Presidion, formerly SPSS Ireland, was set up in Dublin as a regional office of SPSS UK in 1994 to be the main partner office in Ireland.
Part of Version1 in 2020, since then references are lost.
Presidion will today, June 17th 2019, operate under the new name Version 1 Analytics Limited trading as Version 1.
History Crisp-dm
Crip-dm is still valid when the scope is developping models, code.
A recent combination is What is machine learning operations (MLOps)?
The MLOps development philosophy is relevant to IT pros who develop ML models, deploy the models and manage the infrastructure that supports them.
crisp-dm history Cross-industry standard process for data mining.
CRISP-DM was conceived in 1996 and became a European Union project under the ESPRIT funding initiative in 1997.
The project was led by five companies: Integral Solutions Ltd (ISL), Teradata, Daimler AG, NCR Corporation, and OHRA, an insurance company.
This core consortium brought different experiences to the project. ISL, was later acquired and merged into SPSS.
The computer giant NCR Corporation produced the Teradata data warehouse and its own data mining software.
Daimler-Benz had a significant data mining team. OHRA was starting to explore the potential use of data mining.
The first version of the methodology was presented at the 4th CRISP-DM SIG Workshop in Brussels in March 1999,[5] and published as a step-by-step data mining guide later that year.
The crisp-dm document is owned now by:
IBM SPSS
Analtics life cycle Issues
Searching for crisp-dm challenges and data science.
The crisp-dm proces is problematic:
data-science-process
Microsoft has bought "Revoltion Analytics" and is going for an important role at Analytics and BI. Azure cloud computing is the other part.
Although they are using the same step as Crisp_dm there are other issues:
No PDCA, the actions seems to go ad-hoc
Missing is an approach for a value stream
Details on expectation for data acquistion are mising
Nice is the following:
In this stage, you develop a solution architecture of the data pipeline.
You develop the pipeline in parallel with the next stage of the data science project.
Depending on your business needs and the constraints of your existing systems
-//- ,
It is a best practice to build telemetry and monitoring into the production model and the data pipeline that you deploy.
This practice helps with subsequent system status reporting and troubleshooting.
Their approach:
⚙ P-2.2.3 Distractor: Business Intelligence
Evaluating, What others post
Data processing, data warehousing was for a long time isolated for Business Intelligence, analyical plane.
No cooperation to operational processes, no alignment to value streams.
Xomnia M.Imrich
I to IV, Data delivery by =DW support= falls into "business as usual".
LE post
data quadrants
I to IV, Data delivery by =DW support= falls into "business as usual".
data quadrants
P-2.3 BPM - realisations
Business processes are abstract artifacts. It is information, not physical artifacts.
All is existing in an imaginary cyber world.
Results however can have physical instantiations.
Cycled Stages:
Situation / Steer
Input / Inquiry
Activity / Analyse
Request / Results
⟳ P-2.3.1 Processes Cycle Abstraction
⚙ adding PDCA to hierachical pyramid
The PDCA cycle is a standard approach. With DMAIC (Lean Six Sigma) there is an additional control step after an improvement to prevent falling back in old problems.
The picture is getting too crowded, cleaning up the departments that are necessary in the holistic cycle but NOT within the continuously improvement of the business process.
From the hierarchical pyramid only "Business first level" "ICT Analytics" and "ICT Analytics" are used.
Adding the PDCA:
A PDCA cycle in the centre for the overall process.
Using small colored circles in the picture for every involved party doing their work. It covers planning, deadlines with changes.
Only the happy flow is given, when there is a bottelneck a new PDCA cycle is to start.
There are multiple PDCA cycles shown. The size is not to associate with the duration. Act Study Plan should cover more than 80&percnt of the duration time.
⚙ Modifications responsibilities
Modifications on the AIM hierarchy:
Tactical representation (blue) moved outwards, making room for inner circle .
A full big PDCA coloured circle having the "DO "at the bottom (operational) is added with three smaller ones.
The diagonal green and orange lines are departmental involvements.
Preparation of data is done with the help of "ICT Analytics"
Monitoring of scores needs the help of "DS Analytics"
The transformed figure:
⚙ Elaboration vertical-horizontal and diagonals
The visible lines:
Business with four representations in the vertical and horizontal crosshair lines (blue).
The one in the bottom is lacking a clear definition or just being temporary.
"ICT Analyyics" having two representations, a duality from a single department, in the diagonal: bottom-left , top-right (green)
"DS Analytics" having two representations, a duality from a single department, in the diagonal: bottom-right , top-left. (orange)
"ICT Analtyics" ⚙ and "DS Analtyics" are both having different tasks at each of their corners, depending on all the others being involved.
When doing work without any a interactions to the others the focus for each of all is getting the agreed work getting done within deadlines.
⚙ Modifications
Modifications on the AIM + PDCA:
The business leading and deciding for changes in understanding goals and impact.
All crisp-dm stages added at the ML development area (right side).
The deployment in a split up with model monitoring added (left side).
External connections (streaming, api, poc) added at modelling and scoring
Multiple data pipelines (dev - ops) because different set of policy requirements although they are logical / technical similar.
The interaction with the business replacing devops, operations. Any model should not be deployed without pavement for impact by accountable persons.
The figure transforms into:
⟳ P-2.3.2 Controls metrics lines in functions
The need for controls and metrics is not a surprising one neither a new modern insight.
In the physical technical engineering world it is cornerstone for automation.
For only managing the control - measure feedback there is a theory with many practical realisations.
PID controller
❓A question: what happened to the control and metrics in the administrative/cyber world?
Already an old but still valid modelling approach: BPMN (process model)
A standard Business Process Model and Notation (BPMN) will provide businesses with the capability of understanding their internal business procedures in a graphical notation and will give organizations the ability to communicate these procedures in a standard manner.
Furthermore, the graphical notation will facilitate the understanding of the performance collaborations and business transactions between the organizations.
This will ensure that businesses will understand themselves and participants in their business and will enable organizations to adjust to new internal and B2B business circumstances quickly.
...
Credentials are important in the BPM world, where practitioners may work on many projects for different clients or employers over time. The twenty-five experts from top BPM companies and well-known independent consultants who designed the OCEB 2 topical coverage.
... A look inside real-life business processes (Camunda)
Most of these patterns involve reacting to events or handling complex business process logic across multiple endpoints.
Process modeling standards like BPMN were created to design and execute these advanced workflows.
Modeling tools that support BPMN enable a much more effective collaboration between the different stakeholders of a process, such as business users and developers.
In addition, execution tools that support BPMN ensure a reliable, scalable orchestration of the end-to-end process, despite its complexity.
Any actions are possible to model, interactions for monitoring analytics and control are too often missing. Searched for in examples, not found.
in a figure:
⟳ P-2.3.3 Controls & metrics Data Mesh
⚖ Administrative/cyber: Data Mesh, data product quantum
Not knowing what is going on is bad.
The common solition: a huge build environment for BI&A reporting: DWH, Data warehouse, Data Lake, Data Lake House with ETL ELT.
This is a bizar approach not known, not seen in lean agile. 💡❗✅ Simplify operational monitoring in the analytical plane.
From: "Data Mesh Delivering Data-Driven Value at Scale" (book), the data (product) quantum.
The idea: BI&A analytical plane:
🎯 Add a control connection at transformation process. (control: speed, safety)
A moment in time for a change in approach:
A figure:
See right side
⚙ Administrative/cyber: Data Mesh, Experience plane
Not using available information on what is going on is bad.
The huge build environment for BI&A reporting: DWH, Data warehouse, Data Lake, Data Lake House with ETL ELT.
This is a bizar approach not known, not seen in lean agile. 💡❗✅ Simplify operational dashboarding & feedback controls using the analytical plane.
From: "Data Mesh Delivering Data-Driven Value at Scale" (book), the mesh experience.
The idea: BI&A analytical plane:
🎯 Add dashboarding, mesh experience, for the process (speed, safety, capacity)
A moment in time for a change in approach:
A figure:
See left side
P-2.4 BPM - using Jabes
The moment all effort for analysing design and build is getting to deliver possible value is when it gets deployed.
The level of achieved success to measure from metrics.
How to change:
Changing existing situations by understandable increments, continuous change
Overhauling existing situation, preferable: small bangs
Building something completely new is disruptive.
🎭 P-2.4.1 Managing Poduct flows using processes
Not recognized 😱 being important
One would assume the working force for delivering the product servicing the product being seen as key assets for the product line.
Strange enough this assumption is not true.
A very normal seen situation:
Workers being classified: easily replaced by others, for lower cost.
Servicing a product is easily seen as something to be outsourced to other parties without further attention.
Examples are:
A third party call center for solving questions for a product.
A robot that does questions and answers for a product.
The questionaire by a third party For quality experiences on the service.
❓ Question: How would common operational administrative/cyber processes been constructed?
There are many complete frameworks:
for Enterprise resource planning the assumption of a standard commodity service
for a servicedesk supplying standard tools, answering standard questions
for after sales alignment only on short term services by a questonaire
I have never seen those being integrated into a professional holostic set of organisations for product lines services.
Who, in the role as customer, is satisfied by the failure of all assumptions in the "service" that you have a chat robot? Determinants of customer satisfaction in call centres (2016 )
Most companies are increasingly extending their customer service centre beyond the traditional contact centre. Thus, the growing interest in call centres among researchers and business professionals is understandable. Since their advent, call centres have become the main contact channel between companies and customers, and at the same time, they have become a massive employment generator (Aksin et al., 2007; Russell, 2008), and industry in themselves.
However, it seems that customer satisfaction is not traditionally associated with call centre interactions or, at least, academic attention has not been devoted to this topic. Although call centres have been designed as a customer relationship management tool (CRM) in order to assist and support customers, it seems that the study of customer satisfaction in this context has not received much academic attention.
...
From the existing literature on the call centre industry we can identify thirteen KPI: service level (call’s answered within target time), average speed of answer, average time in queue, average abandonment rate, percentage of first call resolution, adherence to schedule, average talk time, after call work time, employee turnover rate, percentage of call’s blocked, time before abandoning, inbound call’s per agent, total call’s (Feinberg et al., 2000).
However, all these metrics were contemplated as internal service quality metrics in former studies (Anton, 1997).
( to be continued - see role)
Product Management is not Project Management although they have both the letters PM.
The process flow
A process administrative/cyber process flow has only a limited set of fixed patterns.
These are: ❶ ALC-V1: a pattern model with the intention of only running once.
The knowledge of the builder is decisive. ❷ ALC-V2: a pattern model with the intention of running regular.
The building and valdiation is based on human decisions. ❷ ALC-V3: a pattern model with the intention of running regular or once.
The building and valdiation is based on computer assisted human decisions (ML AI).
⟳ P-2.4.2 ALC-V1 model
The most simplistic approach. From human knowledge build a process.
⚒ Physical:
The most simple non respective tasks is the normal human cultural approach.
The human nature is also when there is awareness of high risk, the task is avoided.
⚙ Cyber/administrative:
New products new solutions are build without available references maybe even missing the knowledge.
Building in small steps to minimize risks and able to adjust or abandon the solution is the approach to minimize risks and the impact by failures.
Improving maintaining is different although it is still having the goal of running once.
Using the knowledge, experiences of previous similar products is minimizing risks. Typical usage is quarterly annual reports set by regulations.
Self service analytics and spreadsheets are tools being used by topic content specialist in avoiding the overhead and miscommunication by Serve (ICT) staff and even Shape (change) staff.
The best option: 👁 a combination of technical support staff helping the content specialist in a close cooperation.
In a figure:
⟳ P-2.4.3 ALC-V2 model
A more advanced approach. Human knowledge, human decisions building and changing processes.
⚒ Physical:
The industrialisation is using this indicated by mass production and lean production.
Increased productivity with lower cost and higher quality.
⚙ Cyber/administrative:
Using computers the mass production with the lean principles did not get tractions for well working implementations.
There are many frameworks for change, there are many tools that help in realisations, the well designed assembly of a holistic full stack product line is continuously failing.
Missing is the focus on the product line being the goal with all three: quantity quality and cost.
The standard approach developing by humans, validating by humans into the operational usage is the only one full accepted by Serve (ICT) staff and even Shape (change) staff.
The best option: 👁 a full responsibility from Steer (organisation) product line persons.
😱 Functional value stream processing and their technical ICT realisations got confused.
This is caused by volatile uncertain complex ambigue regulations and fast changing technical realisation.
See also: "F-1.4 Misunderstanding: ICT - Business".
In a figure:
⟳ P-2.4.4 ALC-V3 model
A sophisticated approach. Machines are interacting on events themself, balancing by measurements into new situations.
Algorithms for machines and sensors are improving fast using computers in their nice areas.
⚒ Physical:
The feed back loop was quickly used in mechanical industrial solutions. With lean processing it has become a standard to achieve.
⚙ Cyber / administrative:
The change is this is more and faster feed back loops aside the help of machines in choosing the best decisions.
The operational production data is important as source having the experiences of previous similar cases.
In the Cyberworld this feedback loop is the driving factor behind "Artifical Intelligence".
The mindset lock-in from ALC-V2 hampering for better solutions.
The best option: 👁 a full responsibility from Steer (organisation) product line persons.
An important difference is in understanding and using the feedback loops.
😱 The "physical" and "Cyber/administrative" approaches for processes are:
not at same level of maturity
not at same level of understanding
⚖ In a figure:
⟳ P-2.4.5 Data - Information Quality
Stop the line
You don't want to process garbage wrong incorrect information.
You don't want to deliver incorrect wrong information.
Safety measures should be in place for that verifying the functional level of correctness.
Those validations can be logical simple:
#N categories expected to process by historical knowledge vs what is in the input.
#N changes by categories expected by historical knowledge vs what is in the result.
The challenge is that this knowledge is operatioal knowledge.
It is not part of the common ALC-V2 culture using faked test-data. It should be implemented using ALC-V3
It is not part of the common functional culture to have it as operational requirement
It is not part of the operational culture. Even though it is tried by operational staff to solve those issues by bad systems.
"A bad system will beat a good person every time"
P-2.5 BPM - Processes Technology alignment
Product data management (PDM) is focused on capturing and maintaining information on products and/or services through their development and useful life.
⚒ Physical:
Out of scope. The abstract virtual world is the challenging one.
⚖ Legal:
Contracts, negotations are left out of scope although important.
🎭 P-2.5.1 The Product Management role
Not recognized 😱 being important
One would assume the working force for delivering the product servicing the product being seen as key assets for the product line.
Strange enough this assumption is not true.
A very normal seen situation:
(continuation from flows)
Improving a productline on the other hand, gets a lot of attention but lacking the real why's for the improvements.
What I am indicating is missing the focus for:
Quality of the administrative/cyber processing line.
Becoming datadriving while the planning of the processing line is missing.
Going for new technology while the dependencies in the processing line are not understood.
❓ Question: How would the core product be in quality continuity and cost with all this kind of uncertainties?
I have seldom seen accountable management being committed to product quality, it moved to they are only getting involved.
The issue behind this:
key performance indicators (KPIs)
are quantifiable business metrics that corporate executives and other managers use to track and analyze factors deemed crucial to the success of an organization.
Effective KPIs focus on the business processes and functions that senior management sees as most important for measuring progress toward meeting strategic goals and performance targets.
...
To learn more about KPI metrics and any potential areas for improvement, key stakeholders within the organization should be asked for feedback.
The operational stakeholders of a process line:
product manager
water strider
Product Management is not Project Mangement although they have both the letters PM.
The proces life cycle 👁
Going back to the basics where product management is the key player. Going into the core processes, value streams.
The focus in this one is not the operational aspect but changing the operations. ❶ The holistic approach for Product management the full circle of the SIAR model, static & dynamic.
The product is part of a portfolio having specifications. How the product is created is set by requirements. ❷ Assumption: planning enabling with a management decision for the change is fulfilled ❸ The normal operations gets a fork at the old delivery chagning it into an demand for change.
What are the steps in a change steps? Wat is to be done?
IV Ideate - Asses / pull & maintenance: 🎭 These are interactions with the customer
Initiation & maintenance: The customer in this case: the product manager
III Enable - Plan / pull: 📚 Prepare, validate information input
Product Design & Product Build
I Demand - Backend / push: ⟳ Transform conform instructions
Validation Design & Validation Execute
II Frontend - Delivery/ push: 👉🏾 Validate results before handing over
Service evaluation - Delivery: The customer in this case: the product manager
❹ Agile, optimizing work is realised by doing in parallel what is possible to do so.
In engineering there is a lot what has no fixed logical dependencies. This is different in a product assembly line. ❺ having the customer being the product manager the SIAR model has 90° rotated.
In a figure:
See right side
🎭 P-2.5.2 9-plane - Ordering quest (I)
Hierarchical silos
A figure says more than thousand words, but what when the figure is wrong?
Using Steer for the organisation, shape for what was information management, Serve for what was technology, the classic 9-plane places the tactical change activity in the centre. ❶ Is that position of change really the main attribute for organisations? ❷ What has happened with the value stream for missions?
In a figure:
See left side
value stream
The result delivery is going out at the bottom when the visualisation is having "Strategic" at the top.
🤔 Turn the visualisation 90° counter clockwise ⟲ and move Shape to the bottom.
The value stream will be horizontal
The role of the leader changes to an enabler
🎭 P-2.5.3 9-plane - Ordering quest (II)
A figure says more than thousand words, but what when the figure is wrong?
Using Basic for what was operational, Competent for what was tactical, Advanced for what was Strategic and moving shape out of middle, the modified 9-plane places the tactical technology activity in the centre. ❶ Is that position of technology really the main attribute for organisations? ❷ The value stream if going from right to left as the Basic Steer is the delivery. The flow is better to show left to right.
In a figure:
See left side
🤔 Exchange Basic and Advance and exchange Serve and Steer.
The value stream will be left to right
The value stream will be in the core - centre
🎭 P-2.5.4 9-plane - Ordering quest (III)
A figure says more than thousand words.
This one has:
The competent (tacticial) Steer (product line, organisation) in the centre.
Both Shape and Serve are facilitating the organisation. When it would be a three dimensional structure it would be a donut or tube.
Both Shape and Serve are adding services by three laysers.
All accountability and repsonsibility for the administrative/cyber information procesing is within the organisation.
In a figure:
See right side
🤔 There are several culture shocks:
Information processing accountability and repsonsibility withing the organisation
Servant leaders. No classic hierarchy, no focus to change, no focus to technoloy
Revival of the product line and all being involved in product process lines
🎭 P-2.5.5 Naming Conventions, Glossary
Communication for missions
Naming conentions are both for a technical solution and for the daily human communciation important.
It is something I have never seen doing an attempt within with ICT and all their relationships. 📚 Document systems:
archiving knowledge over systems & processes
connecting to business for systems & processes
operational workflows running systems & processes
Avoiding miscommunication is saving a lot.
When the same word is used for "completion of work" and for "destroying the work" the problem starts with finish.
Technical using artifacts
Having well defined set of names associatied with their types and meaning (metadata) is making a technical realization easy.
It would be even far better having a generic standard approach for that.
As those namings conventions aren´t generic, porting the solution to another environment is almost impossible. 🎭 Changing a technology can be a business requirement.
Functional understanding
A naming standard like ibrarians have a succesfull approach. This should include for stages with versioning.
Goal easy to find relevant information, easy to reuse for being common approach. ⚙ Library classification
Library classification is meant to achieve these four purposes: ordering the fields of knowledge in a systematic way, bring related items together in the most helpful sequence, provide orderly access on the shelf, and provide a location for an item on the shelf.
P-2.6 Maturity 4: business processes in control
"Managing technology service" is a prerequisite for "processes: cyber/adminstrative".
Although the focus should be on the value stream processes it starts by the technology connection.
From the three PTO, BPM interrelated scopes:
✅ P - Processes: cyber/adminstrative
✅ T - Managing technology service
❌ O - Organization optimization
⚒ P-2.6.1 Floor experiences
Mythical man month
Underestimating the effort for change, ignoring the capabilities on the floor.
F.Brooks
Brooks observations are based on his experiences at IBM while managing the development of OS/360.
He had added more programmers to a project falling behind schedule, a decision that he would later conclude had, counter-intuitively, delayed the project even further.
He also made the mistake of asserting that one project -involved in writing an ALGOL compiler- would require six months, regardless of the number of workers involved (it required longer).
The tendency for managers to repeat such errors in project development led Brooks to quip that his book is called "The Bible of Software Engineering", because "everybody quotes it, some people read it, and a few people go by it".
The book is widely regarded as a classic on the human elements of software engineering.
👁 First line, second line supervisors
Looking for the cyber/administrative physical equivalent of who accountable for the value stream flow.
The hierarchical implementation is easily missed. These equivalent is missing. The awareness of a values stream is also missing.
Critism Project management.
What the frustrations are, the best is by infographics.:
Swing Tree project
The Dead Horse Theory
Canoe Race...
Agile Waterfall
Customer Journey.
What the frustrations are, is best shown by infographics. The metro line of London is an option for getting lost.
Although Agile Waterfall is the work that is expected to do is not in this paragraph but in P-3.6 the micromanagement approach wit all nor realistic assumptions is the shared frustration and impediment for real lean real agile.
⟲ P-2.6.2 Control wish, floor result
👁 First line, second line supervisors
Looking for the cyber/administrative physical equivalent of who accountable for the value stream flow.
The hierarchical implementation is easily missed. These equivalent is missing. The awareness of a values stream is also missing.
The result of strict control management.
What the frustrations are, is best shown by infographics.
Swing Tree project
A very old one showing the steps in a customer journey for delivery a toy, "swing tree".
It is a classic. Having seen already in the 80´s and never got outdated as legacy.
How the customer explained it
How the Project Leader understood it
How the Analyst designed it
How the programmer wrote it
How the Business Consultant described it
How the project was documented
What operations installed
How the customer was billed
How it was supported
What the customer really needed
The Dead Horse Theory
Buying a stronger whip.
Changing riders.
Threatening the horse with termination.
Appointing a committee to study the horse.
Arranging to visit other countries to see how others ride dead horses.
Lowering the standars so that dead horses can be included.
Re-classifying the dead horse as "living impaired".
Hiring outside contractors to ride the dead horse.
Harnessing several dead horses together to increase speed.
Providing additional funding and/or training to increase the dead horse´s performance.
Doing a productivity study to see of lighter riders would improve the dead horse´s performance.
Declaring that as the dead horse does not have to be fed, it is less costly, carries lower overhead , and therefore contributes substantially more to the bottom line of the economy than doe some other horses.
Rewwriting the expected performance requirements for all horses.
Promoting the dead horse to a superviory position of hiring another horse.
Canoe Race...
Another famous one.
A clear overkill by managers micromanagement.
Blaming the worker not fullfilling unrealistic expectations.
Rewarding managers for the excellent peformance.
Of course there are a lot more than those. What is not mentioned in these two infographics is:
Lack of coöperation by not shared business goals (silo´s).
Not willng to change with correct effective working innovations.
Agile Waterfall ...
comicagile
Don´t take a waterfall approach to working agile; the DoR, A.C. and DoD are not gates, and even after starting development, you can refine your stories further, so don’t let the direction of your workflow, represented by the activities on your Kanban board, trick you into doing the activities only serially.
⟳ P-2.6.3 Wish: In control with processes
Putting the product process line in the middle allows to show acting on simple adjustments (Steer-Serve) and ones with more impact (Serve-Shape).
The figure,
See right side:
📚 P.2.6.4 External references
Global compliancy
These references are at the index, they are a shared interest.
❌ ✅ Shared glossary with cooperation for technology and change
❌ ✅ Responsibility for clear security and other regulations at the shop floor.
❌ ✅ Responsibility for managing processes by well defined instruction at the shop floor.
These are to be understood solved and managed by management at the high levels. This can be measured by maturity metrics.
The usual situation is: none of them is in place. Worse, there is even no awareness, CMM level-0.
Managing the organisation is balancing act in a hierarchical command and a network shared interests approach.
👁 P-3.1.1 Mindset prerequisites
Servant leader
What is servant leadership? A philosophy for people-first leadership
Servant leadership is a leadership style that prioritizes the growth, well-being, and empowerment of employees.
It aims to foster an inclusive environment that enables everyone in the organization to thrive as their authentic self.
Whereas traditional leadership focuses on the success of the company or organization, servant leadership puts employees first to grow the organization through their commitment and engagement. When implemented correctly, servant leadership can help foster trust, accountability, growth, and inclusion in the workplace.
....
The theory of servant leadership was started by Robert K. Greenleaf, who popularized the term in a 1970s essay titled “The Servant as Leader.”
After reading the book Journey to the East, Greenleaf was inspired by the main character, Leo, a servant who disappears from work.
After his disappearance, the productivity and effectiveness of the rest of the workers falls apart, revealing that Leo was in fact a leader all along.
This led Greenleaf to believe that servant leadership is effective in its ability to allow workers to relate to leaders and vice versa, creating more trust and autonomy for workers.
Greenleaf first put this theory to test while working as an executive at AT&T, and it’s gained traction over the years as an effective leadership style.
Inverted pyramid idea Robert Greanleaf.
Person of character: A servant leader is someone who maintains integrity, makes decisions based on ethics and principles, displays humility and serves to a higher purpose in the organization.
Puts people first: A servant leader demonstrates care and concern for others and helps employees meet their goals and grow within the organization.
Skilled communicator: Communication skills are integral to servant leadership, and you will need to ensure you can effectively listen to and speak with your employees, while also inviting feedback.
Compassionate collaborator: To be a strong servant leader, you’ll need to consistently work with others and work to strengthen relationships, support diversity, equity, and inclusion, and navigate conflict in the workplace.
Has foresight: As a servant leader, you will need to keep an eye on the future and anticipate anything that might impact the organization. You’ll also need to have a strong vision for your organization and be the type of person who can take decisive action when needed.
Systems thinker: Servant leaders need to be comfortable navigating complex environments and able to adapt to change. This type of leadership requires strategic thinking and the ability to effectively lead change in the organization.
Leads with moral authority: As a servant leader, it’s important to establish trust and confidence in your workforce by establishing quality standards, accepting, and delegating responsibility and fostering a culture that allows for accountability.
Servant Leadership: Breakthrough Ideas on Customer Service (James MacLennan 2020 )
The traditional org chart is all wrong. It puts the people that work directly with your customer at the lowest position on the pyramid.
This makes the customer the least important person in the picture. Servant Leadership will flip that pyramid.
What if your leaders saw their primary mission as support for those closest to the customer?
What kind of difference would that have on customer loyalty and satisfaction?
...
There is another important idea that we all grew up with – something that dominates how we see the world and our place in it. Organizations are strict hierarchies; CEO at the top, supported by a team of Execs, and a progression of managers below.
This structure is always drawn as shown – CEO at the top, with the organization cascading down the page.
....
Here is the secret … this entire structure is upside down! Why?
Because it puts the people on the front lines – the folks that work directly with your customers – at the lowest position in this pyramid.
This point of view makes the customer the least important person in this entire picture.
But what if we flipped the pyramid? What if the folks [formerly] at the top considered “service and support for those closest to our customer” to be their primary mission?
....
Inverted Pyramid - Applications
Using an inverted pyramid is not new.
This as a very old image, the origin is Ageyff 1969 Nato meeting for discussing the software crisis. Another wall known visitor was E.W.Dijkstra.
The layers top-down are:
🎭 Applications
📚 Middleware. ➡ DBMS tools, platforms
🔰 Service routines, Control Program. ➡ Infrastructure, operating system, networking.
Reusing this kind of separation of concerns gives another remark.
👁 P-3.1.2 Separation of concerns
Conflict of interests
The dilemma is what is having the priority.
Innovation vs Stable operations:
Starting with an innovation and than making that robust and stable or
Making the running processes stable and than innovate.
That question is of getting answerers to business value and complexity - simplicity.
A start-up doesn´t need to get answer on that.
labeling the quadrant:
Doing things as used to be (push) rigid but: predictable repeatable reliable.
Ideal combination of new innovations and being trustworthy.
Adhoc, nothing as should be operational or legal but maybe having the necesssary new opportunities.
Innovation, changing the business by doing things different. (pull)
Obvious is "doing things different" is conflicting with "doing things as usual".
Attempts solving innovation vs operation
The challlenge to solve the conflict is an mission impossible.
The resulting issues are well known for a very long time.
People architecting engineering have a different psych doing changes innovation than the ones good at operations.
When doing deployments implementing changes or just proposing change, conflicts are lurking.
SukumarNayak (2015)
has a nice presentation on all kind of organizational issues.
He refers to Business–IT alignment. (what is devops)
Business-IT alignment is a process in which a business organization uses information technology (IT) to achieve business objectives -
typically improved financial performance or marketplace competitiveness.
Some definitions focus more on outcomes (the ability of IT to produce business value) than means (the harmony between IT and business decision-makers within the organizations).
going into What is IT-business alignment and why is it important?
CIOs and their IT teams must still deliver utilitarian technology services, Topham said. But they must also now have the capacity to strategize how technology can shape what the enterprise offers for products and services as well as how it delivers those offerings.
"This is where alignment is manifested," he explained. "It's where everyone from both sides is bringing something to the table for communal benefits. There's no 'them' and 'us.'"
A figure showing the "wall of confusion":
👁 P-3.1.3 People Position quest at the organisation
Hierarchical top-down
This is the well known classic top-down hierachical control.
A figure,
See right side:
Flow - values stream map
The Five Maps of Flow Engineering
Adapted from the book Flow Engineering: From Value Stream Mapping to Effective Action by Steve Pereira and Andrew Davis. (2024)
Flow Engineering builds upon mapping’s benefits to go beyond engagement, alignment, and focus. It enables effective collective action.
Flow Engineering allows us to identify value by connecting current state context to a clear target outcome.
It connects that outcome to specific benefits for customers and stakeholders. It keeps that value present as a north star so that contributors can make the best decisions about what will help boost and uncover value through their efforts.
Five key Flow Engineering maps enable the three elements of action:
Outcome Map: To identify your target outcome.
Current State Value Stream Map: To reveal the current state and constraints of your workflow.
Dependency Map: To identify dependencies by studying constraints.
Future State Value Stream Map: To create a future state definition of flow.
Flow Roadmap: To organize insights, actions, and ownership into an improvement roadmap.
...
This Plan-Do-Study-Act (PDSA) cycle is also known as the Deming or Shewhart cycle. The goal is to establish improvement as a habit.
...
One of the biggest risks in any improvement initiative is improving the wrong thing.
It’s wasteful to improve part of the process that doesn’t have a significant impact on the whole.
It’s also wasteful to gather more data than necessary to determine where improvements can be found.
Rotaded plane overhauled, Jabes
The hierarchical orientation does not match when working in flows, value streams.
Repositioning planes that is does match with a flow left to right, the enterprise organisation in he centre:
The figure,
See right side:
P-3.2 Visions translations into missions
Before a mission can be started equipment must be in order:
trained staff
possible activities
available equipment
Without authority, a leader cannot direct and guide their followers towards a common goal.
Without accountability, a leader cannot be held responsible for their performance and outcomes.
⚙ P-3.2.1 Managing, controlling ALC-V3
ALC-V3 details, linear timelines
Instead of using a circle for the cycle a linear timeline help in understanding timing dependencies.
What is in the figure::
The vertical dashed green lines are the releases of code versions.
There are at least three of them.
The two code repositories "data information quality", the result archive and result copy are other ones.
Data information Gathering (Extract), conform an agreed contract.
Data processing to split in:
Data transformation into a usable setup (ABT Analytical Base Table).
rule based transformation (Process Score) into information results.
Delivering, load, of the result (scoring) conform an agreed contract.
A developing line where the code, model, is developed (the coloured hexagons).
The operational line containing the business value, goal, controlled verifiable.
The full crowded picture "SDLC" without all possible DTAP layers:
⚙ P-3.2.2 Managing partial processes ALC-V3
Simplified processing cycle
Defining a process in four phases is no classic culture.
The Five Maps of Flow Engineering
Future State Mapping happens in four stages:
IV Review the target outcome and findings from previous maps.
III Identify targets for improvement.
I Redesign the stream.
II Measure the future state.
The acceptance to do that is is steep because when visualised the starting & end point are not intuitive when the flow is leading.
For a distributed data platform to be successful, domain data teams must apply product thinking with similar rigor to the datasets that they provide;
considering their data assets as their products and the rest of the organization's data scientists, ML and data engineers as their customers.
...
need to have the following basic qualities:
Discoverable
A data product must be easily discoverable. A common implementation is to have a registry, a data catalogue, of all available data products with their meta information such as their owners, source of origin, lineage, sample datasets, etc. This centralized discoverability service allows data consumers, engineers and scientists in an organization, to find a dataset of their interest easily.
...
Secure and governed by a global access control Accessing product datasets securely is a must, whether the architecture is centralized or not.
There is a figure for the data product qutum (A-1.4.1).
An alternative for this is the follow figure:
The cycle: interaction with the customer
For any request - delivery there is cycle. Note the location of the custom.
See figure:
Continuous: Working at Ideate Plan (WIP)
Developing building validating is done as much in parallel as possible.
There is no need to have all details being clear as long there is a trust it can be solved fulfilling the goals.
Even architecting and designing can be done while building and validating is work in progress.
Work in progress:
Any step: no need to complete finished, starting the next one ❗
⚙ P-3.2.3 Managing Operational Streams ALC-V3
Happy Flow
The operational pipeline has four dashed pink lines.
Extracting, retrieving validating data - information.
Loading, transforming data - information into an usable lay-out.
Transformation, processing of the the data - information into new information products.
Delivering the result or have it available when requested.
The picture in focus:
Watch dogs
The operational pipeline has controls, includes monitoring.
Watch dogs:
Input validations, includes data quality with specfified profile levels.
Output validations, includes data quality with specfified profile levels.
The monitoring of scoring results has two blue lines and two storage containers.
The logic is archiving the scoring results for several goals:
operational compliancy, what was delivered, ahata was used for the delivery.
Knowing what is happening with scores might be very important information.
An unstable profiling result will cause legal problems.
Improvement, innovation, different retention policies enabling learning.
Synthetic information is useless when wanting what is yet unknown.
For the business analyst, data scientist it is important to be able analyze production score results without having a connection into that operational processes possible harming it.
The picture for in focus is like:
Attention points Score monitoring:
Scoring results are best stored incremental information chain with time marks.
For retrievals of scoring a reverse logic is needed, denormalizing.
P-3.3 Regulations, compliant processes
During performing a mission, equipment must be in order:
trained staff
possible activities
available equipment
Without authority, a leader cannot direct and guide their followers towards a common goal.
Without accountability, a leader cannot be held responsible for their performance and outcomes.
⟲ P-3.3.1 Requirements Regulations, catgorisation
⚖ Obligations
It is not only blindly following instructions managing the product process flow.
The value stream has mandatory requirements to be fulfilled to be shown for the products in the portfolio.
During design and validation of the product they should get materialized.
As long the product is relevant, that is customers are using it or are able to refer it, the information of the portfolio product for dedicated version should be at least retrievable.
To get covered by information knowledge by a portfolio:
Security architecture (technical)
Operational risk (functional)
Privacy - impact
Process - impact
In a figure:
See right side.
⚒ Additional layers Jabes portfolio
The scope in information strategy is until now limited to what is happening in an organisation.
Critical services int the social community are not bound anymore to a single organisation, it has become a chain of organizations with interactions and dependencies. ❶ The service chain of layers layers:
🎭 Services: ➡ multi enterprise systems, multi-accountablities value streams
📚 Systems: ➡ single enterprise scope, single-accountablity value streams
🔰 Applications
Extending to systems and services is just another new Jabes meta identification. ❷ The classic layers are:
🎭 Applications
📚 Middleware. ➡ DBMS tools, platforms
🔰 Service routines, Control Program. ➡ Infrastructure, operating system, networking.
👉🏾 The description of Jabes (C-Jabes) was made with this classic in mind.
🤔 There is a resemblance: OSI model (Open Systems Interconnection)
The osi model ends at the top with layer-7 "application".
The osi context for application is:
The application layer enables the user -- human or software -- to interact with the application or network whenever the user elects to read messages, transfer files or perform other network-related tasks. Web browsers and other internet-connected apps use Layer 7 application protocols.
That are service routines in the classic layers where the application is something interacting with an operator.
❸
Information value chains is leading to connected systems and multi-stakeholder systems, making it difficult to untangle webs of information value chains.
Additionally, standards organizations are emerging as information value chains, making money through consensus expertise and licensing fees.
These organizations recruit volunteers, consultancy shops, and vendors to contribute to standards, aiming to minimize operational expenses and ensure feasibility.
However, this proliferation of standards is leading to standards wars, making it challenging to achieve a consensus on security standards
⚙ Cooperation
All the necessary knowledge is impossible to fulfil by a single person.
Cooperation is communicating with other persons. The communication is by hierarchy line and by capabilities lines.
In an incremental process:
Shared information of work in progress
Shared understanding of the direction
There is, or should be, a "Hoshin Kanri" or X-matrix.
A clear statement on what the vision on functional missions are.
Review of the design, incremental.
The earlier issues are recognized the better faster and cheaper corrections are.
Correction or remarks on review results
The earlier issues are recognized the better faster and cheaper corrections are.
This is a process in his own with the goal of only going that far in details others can start their work while covering at least known mandatory requirements.
⚒ Applicable regulations
This is a growing list. Many are for a particular segment in the market, others are generic.
For administrative/cyber there are frameworks but what is applicable by regulations is by a segment in the market.
An example, PCI security standards: PCI SSC Overview
PCI Security Standards are developed specifically to protect payment account data throughout the payment lifecycle and to enable technology solutions that devalue this data and remove the incentive for criminals to steal it.
They include standards for merchants,service providers, and financial institutions on security practices technologies and processes, and standards for developers and vendors for creating secure payment products and solutions.
See figure:
⟲ P-3.3.2 Safety, Information Security
Topics:
Risk Analysis and Information Systems Security Policy: Implementing policies for risk analysis and the security of information systems.
Incident Handling: Including measures to prevent incidents and mitigate their impact.
Business Continuity Measures: Such as backup management, emergency planning, and crisis management.
Supply Chain Security: Addressing security-related aspects concerning suppliers and service providers.
Security in Acquisition, Development, and Maintenance: Ensuring network and information systems security, including vulnerability response and disclosure.
Assessment of Cybersecurity Risk Management Measures: Policies and procedures to evaluate the effectiveness of cybersecurity risk management measures.
Basic Cyber Hygiene Practices and Cybersecurity Training: Implementing fundamental cybersecurity practices and training.
Cryptography and Encryption Policies: Policies and procedures regarding the use of cryptography and encryption.
Personnel Security, Access Policies, and Asset Management: Security aspects related to personnel, access policies, and asset management.
Multi-Factor Authentication and Secure Communication: Utilizing multi-factor authentication or continuous authentication solutions, secure communication, and emergency communication systems.
Coordinated Vulnerability Disclosure Policy: Policies for the coordinated disclosure of vulnerabilities.
These measures and procedures are designed to protect network and information systems from incidents and to effectively manage cybersecurity risks in accordance with applicable standards and regulations.
⟲ P-3.3.3 Data, Information Quality
Data, information Quality is a well known challenge. data quality .
Data quality is a measure of a data set's condition based on factors such as accuracy, completeness, consistency, reliability and validity. Measuring data quality can help organizations identify errors and inconsistencies in their data and assess whether the data fits its intended purpose.
Organizations have grown increasingly concerned about data quality as they've come to recognize the important role that data plays in business operations and advanced analytics, which are used to drive business decisions. Data quality management is a core component of an organization's overall data governance strategy.
Data governance ensures that the data is properly stored, managed, protected, and used consistently throughout an organization.
...
Various methodologies have been developed for assessing data quality.
For example, data managers at UnitedHealth Group's Optum healthcare services subsidiary created the Data Quality Assessment Framework (DQAF) in 2009 to formalize a method for assessing its data quality.
The DQAF provides guidelines for measuring data quality based on four dimensions: completeness, timeliness, validity and consistency.
Optum publicized details about the framework as a possible model for other organizations.
The International Monetary Fund (IMF), which oversees the global monetary system and lends money to economically troubled nations, has also specified an assessment methodology with the same name as the Optum one.
Its framework focuses on accuracy, reliability, consistency and other data quality attributes in the statistical data that member countries must submit to the IMF.
In addition, the U.S. government's Office of the National Coordinator for Health Information Technology has detailed a data quality framework for patient demographic data collected by healthcare organizations.
Work to do.
⟲ P-3.3.4 Privacy, Explainable Pii usage
Generic, Social media
Privacy, Explainable Pii usage is getting a lot of attention.
There are not clear set guidelines for implementations on this moment.
In the hype and buzzing there is a lot of confusion.
Health
There a lot of guidelines for using information in this area.
Work to do.
Finance
There a lot of guidelines for using information in this area.
Work to do.
⟲ P-3.3.5 Business Rules, Explainable Algorithms, Diamonds
Generic, Social media
Algorithms, Artificial intelligence usage is getting a lot of attention.
There are not clear set guidelines for implementations on this moment.
In the hype and buzzing there is a lot of confusion.
Standard Information processing
There is long history for busienss rules, requirements logic.
To be short the knowledge how something is working, programmed, what is should do, is not easy availabble. Goal Jabes:
Consolidating what is known.
Enabling controlled change to what is done .
👉🏾 The idea of Jabes started by this gap.
P-3.4 Information culture alignment
After a mission results are evaluated for:
staff healthiness
executed activities
equipment condition
Without authority, a leader cannot direct and guide their followers towards a common goal.
Without accountability, a leader cannot be held responsible for their performance and outcomes.
⟳ P-3.4.1 Product control managing Planning flows
Not recognized 😱 being important
One would assume the working force for delivering the product servicing the product being seen as key assets for the product line.
Strange enough this assumption is not true.
A very normal seen situation:
Workers being classified: easily replaced by others, for lower cost.
Servicing a value stream (a core service) is not recognized to be an important activity.
Better stated the operations realisation of services are felt not important when there are no issues no problems.
Symptoms seen:
Management by incidents, problems by escalations.
Failing to recognize and manage foreseeable breakdowns in core services.
Going to external parties, advisories to solve internal value streams issues.
❓ Question: How would operational administrative/cyber processes become trustworthy?
There are many tools, complete frameworks, assumptions:
Enterprise monitoring: solved by external parties (SOC Security Opertions Center).
Network services: installing, configuring, solved part by external parties.
Tools applications: roles, access, solved part by external parties.
I have never seen those being integrated into a professional holostic set of organisations for product lines services.
Who, in the role as customer, is satisfied by the failures of all assumptions in the "service" for availability confidentialty integrity? ❶
Analysis of production scheduling initiatives in the manufacturing systems (2020 - sunday a. afolalu, omolayo m. ikumapayi, samson o. ongbali, samuel o. afolabi )
The desire of every production company is profit maximization. To accomplish this competitive goal, the company wishes to meet up with the demand of its customers. Market demands are defined in two terms viz could be real or forecast demand. In pursuit of the goals, the company set out production strategies by preparing a production schedule plan of how the various products will be made over a specific time with the number of such products to be sold.
... Production scheduling is an active level of decision making that covers not only the production phase of the product life cycle, but also the use phase of the process’s life cycle.
❷
Designing and developing smart production planning and control systems in the industry 4.0 era: a methodology and case study (Journal of Intelligent Manufacturing 2022 - Olumide Emmanuel Oluyisola1, Swapnil Bhalla1, Fabio Sgarbossa1, Jan Ola Strandhagen )
In furtherance of emerging research within smart production planning and control (PPC), this paper prescribes a methodology for the design and development of a smart PPC system.
A smart PPC system uses emerging technologies such as the internet of things, big-data analytics tools and machine learning running on the cloud or on edge devices to enhance performance of PPC processes.
( to be continued - see process control)
Product Management is core business. Product Plan control is core busisnnes, core of lean.
⟳ P-3.4.2 Values streams - Product Plan Control
Human Plan Control
Blind executing is not very smart. This is another type of "request - input - process - output - result" cycles.
How to approach and solve this is similar using SIAR PDCA DMAIC etc. only applied to this operational planning.
To remember Lean PDCA has his origins in this operational plan.
Analysing, planning, predicting - forecasting, prescribing what is to be executed is the way to go.
The layers involved for a planning has several inputs (features).
Figures are from "Analysis of production scheduling initiatives in the manufacturing systems".
Machine assisted Plan Control
Planning is complicated, not and easy algorithm.
The classic approach is having somebody doing it.
Gathering information from several sources opens an apporach having computers, machines support in the planning.
The decision on what to do still by a human.
Figures are from " Designing and developing smart production planning and control systems in the industry 4.0 era ".
⟳ P-3.4.3 Add the PDCA to Enterprise Ontology
Enterprise engineering ontology in a cycle
In the business development area a full SDLC life cycle is described with many topics with three power lines of involved parties.
Strategy (blue). BPM and Analytics are the most powerfull lines
Operational Business processes (red). SDLC as most powerfull line
Changing business processes (green), initiated in accordance to strategy. SDLC as most powerfull line
⚠ In every area of the three colored segments a representation of the basic power lines is found.
The SDLC process life cycle is based on four quadrants, not three segments.
This is not an easy fit tot align in visualisations.
Two addition small representatives are needed in the upper quadrants (I,II) whereas the lower (III,IV) it is already shared.
Artifacts in the cycle are for SDLC and hidden ones for the enterprise.
Changing Services - Processes
⚠ It is far more difficult to adjust an existing process than just building a new one.
I, make an inventory of new proposals from a existing processes
II, preparing new proposals
IV, realising the proposals
III, Implementing changes as new processes and execute those
⚠ The horizontal compliancy lines are adjusting what is in progrees. ⚠ The vertical alignment lines are for adjustments what is in progress.
The whole new process is in scope for this, a future promised outcome, expectation.
In a figure:
⟳ P-3.4.4 Goal: Data driven processes
Compliancy functional location Accountablity
❶ The accountability and most of the responsibility for information (data / information) is at the "Data Controller" not at the "Data Processor".
Outsourcing accountability is legally not possible although that mistake is too often attempted. ❷ Compliancy regulations are set for "Data Controllers".
Following regulations are "Data Processors" verified by the controllers to assure rules guidelines are met within boundaries. ❸ ❓ Question Who is managing information?
Managing information only can be solved within the organisation❗
This ascertainment is:
a change in the usual culture: information processing is for technology guys
requires dedicated tasks and roles to be placed within the organisation
requires awareness and knowledge on processes within the organisation
Data driven operational realisation
When you want to build much software doing many deployments using data as the source of information, the following is a good approach.
Typical characteristics:
A horizontal line West-East touches the points in the circular process for compliancy reviews.
In a top down approach, there are four stages:
Ideate - Asses, Enable - Plan
Design - Build - evaluate
Accept yes/no, deploy
Build - operate - evaluate
The development can be in any ALC-V* type.
This process is a combination from PDCA, AIM model and Crisp-DM. Adding deployment, monitoring and compliance all equally important parts of the cycle
👁 Fast changing available technology (hypes) is in scope, are an option. ⚠ Attention on aspects:
Maturity,
quality of information,
possible impact caused by results
In a figure:
P-3.5 BPM Technology Change alignment
Product data management (PDM) is focused on capturing and maintaining information on products and/or services through their development and useful life.
Change management is an important part of PDM/PLM.
⚖ Legal:
Contracts, negotations are left out of scope although important.
🎭 P-3.5.1 Wish: In control with processes
Recognized being important but 😱 lost in space
One would assume a safe working environment is a logical requirement that is in place.
This assumption is not true for several reasons.
A very normal seen situation:
(continuation from flows)
A safe working environment is seen as a cost factor, not adding value.
Cyber security is going with a lot of investment costs.
Improving a productline on the other hand, gets a lot of attention but lacking the real why's for the improvements.
What I am indicating is missing the focus for:
Quality of the administrative/cyber processing line.
Safety of the administrative/cyber processing line.
Accepting short term approaches, not understanding the PDCA.
❓ Question: How would the core product be in quality continuity and cost with all this kind of uncertainties?
There is a mandatory change by regulations coming: ❶ NIS-2 (Directive (EU) 2022/2555)
The number, magnitude, sophistication, frequency and impact of incidents are increasing, and present a major threat to the functioning of network and information systems.
As a result, incidents can impede the pursuit of economic activities in the internal market, generate financial loss, undermine user confidence and cause major damage to the Union’s economy and society.
Cybersecurity preparedness and effectiveness are therefore now more essential than ever to the proper functioning of the internal market.
Moreover, cybersecurity is a key enabler for many critical sectors to successfully embrace the digital transformation and to fully grasp the economic, social and sustainable benefits of digitalisation.
❷ Dora (Regulation (EU) 2022/2554)
In the digital age, information and communication technology (ICT) supports complex systems used for everyday activities.
It keeps our economies running in key sectors, including the financial sector, and enhances the functioning of the internal market.
Increased digitalisation and interconnectedness also amplify ICT risk, making society as a whole, and the financial system in particular, more vulnerable to cyber threats or ICT disruptions. ...
To date, due to the ICT risk related provisions being only partially addressed at Union level, there are gaps or overlaps in important areas, such as ICT-related incident reporting and digital operational resilience testing,
and inconsistencies as a result of emerging divergent national rules or cost-ineffective application of overlapping rules. ...
As the Single Rulebook has not been accompanied by a comprehensive ICT or operational risk framework, further harmonisation of key digital operational resilience requirements for all financial entities is required. ...
What is new:
duty of care Carry out a risk assessments, the base for appropriate measures.
reporting obligation: dedicated incidents to the supervisor within 24 hours.
Registration obligation Applicable entities for NIS2, Dora are required to register.
Supervision Compliance obligations, eg the duty of care, reporting, are examined.
Existing security frameworks are not obsolete, they are the ones for appropriate measures.
A regulation is immediate active, a directive has an obligation to the member state.
Product Management is including a lot, aside line functionality also safety.
🎭 P-3.5.2 A Safe environment quest (I)
Stop the line, being lean, cost saving
Keep Calm and Stop the Line—Part 2
In manufacturing, a common sentiment is that the line (or generally the process) must run.
There is some truth to that, but—counterintuitively—for a system to run well you need to know when to stop it too.
This is my second post in a series giving you an overview on when it may be better to stop the line rather than keeping it running (and making everything worse).
Hence, your operators need to stop the line if there are problems that they cannot resolve within the cycle.
This is even the justification for the well-known Toyota approach of Jidoka, or autonomation.
Jidoka means a process stops automatically if there are any irregularities.
Yet, you want to stop the line as little as possible. For this there is the andon line pulled by the operator in case of problem. This pull gives signal to an andon board, which then calls help.
The key here is to provide help to the operator quickly.
If the operator has to fill out a maintenance request so that maintenance shows up two hours later, then your line stops for at least two hours, which is a bit much.
Stop the Line If There Is a Safety Risk!
Another reason to stop the line is if there is a safety risk. The health and safety of your operators should be paramount to your production output, and a health risk (both short-term accident and long-term hazards) must stop the line.
A secure safe environment
The Toyota KPI Dashboard—Safety
Safety is also one of the main headings of the Toyota Hoshin Kanri, their structure for setting targets from the top down across all hierarchies.
I found pretty much everywhere is the safety cross. This is a simple cross with the days of a month (i.e., 1 to 31). Every day the previous day is filled out.
Green stands for no accident. Yellow stands for a minor accident. And red stands for a major accident. Throughout the month a very visual representation of the safety statistic emerges.
Similar visualizations are used in many plants. If for religious reasons a cross is undesirable, I have also seen a safety “S.”
Involved & comitted persons for a safe environment
Stopping the line is mandatory done when a data breach or successful cyber attack is seen.
With NIS2 and Dora the cybersecurity should brought at a level that the expected risk/impact is at an acceptable level.
What is new:
Accountablity: Clear set to executives of the organisation for important services.
External providers (Dora): When part of a comitted service, included for all activities.
The standard hierarchy (strategy tactical operations) gives a process by two loops.
A figure,
(NIST CSF 2.0)
See right side
🎭 P-3.5.3 A Safe environment quest (II)
Security frameworks
For the administrative/cyber world
CSF 2.0 Nist
The Cybersecurity Framework (CSF) 2.0 is designed to help organizations of all sizes and sectors — including industry, government, academia, and nonprofit — to manage and reduce their cybersecurity risks.
It is useful regardless of the maturity level and techncal sophistication of an organization’s cybersecurity programs.
Nevertheless, the CSF does not embrace a one-size-fits all approach.
Each organization has both common and unique risks, as well as varying risk appetites and tolerances, specific missions, and objectives to achieve those missions.
By necessity, the way organizations implement the CSF will vary.
Ideally, the CSF will be used to address cybersecurity risks alongside other risks of the enterprise, including those that are financial, privacy, supply chain, reputational, technological, or physical in nature.
To control govern the process there is cycle:
A figure,
(NIST CSF 2.0)
See right side
This one is confusing: ❶ The left cycle is the process to act on an event, the rihgt numbering with a "repeat&repeat is the preparation planing etc to be able to act on a event. ❷ usuallly a reference to a PDCA cycle with fout stages is done.
One of many other frameworks is: 6 phases incident response plan
Note the differences in words when the focus is on recovering from a breach:
Preparation This phase will be the work horse of your incident response planning, and in the end, the most crucial phase to protect your business.
Your response plan should be well documented, thoroughly explaining everyone’s roles and responsibilities. Then the plan must be tested in order to assure that your employees will perform as they were trained.
The more prepared your employees are, the less likely they’ll make critical mistakes.
Identification This phase will be the work horse of your incident response planning, and in the end, the most crucial phase to protect your business.
Your response plan should be well documented, thoroughly explaining everyone’s roles and responsibilities. Then the plan must be tested in order to assure that your employees will perform as they were trained.
The more prepared your employees are, the less likely they’ll make critical mistakes.
Containment When a breach is first discovered, your initial instinct may be to securely delete everything so you can just get rid of it.
However, that will likely hurt you in the long run since you’ll be destroying valuable evidence that you need to determine where the breach started and devise a plan to prevent it from happening again.
Eradication Once you’ve contained the issue, you need to find and eliminate the root cause of the breach.
This means all malware should be securely removed, systems should again be hardened and patched, and updates should be applied.
Recovery This is the process of restoring and returning affected systems and devices back into your business environment.
During this time, it’s important to get your systems and business operations up and running again without the fear of another breach.
Lessons Learned Once the investigation is complete, hold an after-action meeting with all Incident Response Team members and discuss what you’ve learned from the data breach.
This is where you will analyze and document everything about the breach.
Categorization
There is a lot to do, a categorziation suitable to metadata identifications is helful in simplifying the work.
A good starting point is (NIST CSF 2.0):
🎭 P-3.5.4 A Safe environment quest (III)
Creating Safety Profiles
This cycle for setting safety profiles is a continuous process out of scope of the practical realisation.
It is input what is wanted at realisations.
A feed back for unrealistic expectations should be in place.
Putting several cycles into Jabes
There are several cycles:
Using invented scenarios knowing the environment and using open source known vulnerabilities:
Delivery review (Plan) Communicate what to learn, options for improvements.
Preparations (Do) Realisation of proposed improvements..
Analyse Scope: (Check) goal limit to what is applicable & avoid overload.
Analyse adverse effects: (Act) Avoid being the cause of unintended outages.
The goal is an assumed safe environment but events can still happen.
Several steps are avoided because of involved impact. These need to be designed engineered build and validated their own cycle:
Continuity Recovery From several scenarios that systems are corrupted or unavailable how to solve those.
Monitor & respond What is monitored for possible signals covering scenarios.
Stop the line How to isolate and contain in case of events from scenarios.
Root cause mitigations Form scenarios what possible actions are.
The goal is getting prepared for the unexpected.
The full circle: validate what is prepared is an action on regular planned time schedules.
Counting then number of process cycles and adding the govern cycle there are eight of them to manage and one supervisory.
The profile circle, govern circle, full circle (act on event), preparation, four for details.
The location of he PDCA is an inidcator that the customer, sponsor, accountability role is at the C-Shape pillar.
In a figure:
P-3.6 Maturity 5: PDCA business processes
"Managing technology service" is a prerequisite for "processes: cyber/adminstrative".
Although the focus should be on the value stream processes it starts by the technology connection.
From the three PTO, BPM interrelated scopes:
✅ P - Processes: cyber/adminstrative
✅ T - Managing technology service
✅ O - Organization optimization
⚒ P-3.6.1 Maturity fundaments organisation
👁 First line, second line supervisors
Looking for the cyber/administrative physical equivalent of who accountable for the value stream flow.
The hierarchical implementation is easily missed. These equivalent is missing. The awareness of a values stream is also missing.
Expectations Project management.
At complicated situations everybody can be right, form his viewpoint.
Viewpoints being that different they can´t be true both.
USing other words, hypes, working approaches: Scrum, Agile, Lean six sigma, Kanban.
Using shared technology easily runs into conflicts.
🤔 The most understandable question as result is having a dedicated machine for each "application".
This is not sensible when the information process as core business gets broken by disparate connections between machines.
Government Organisation using technology.
This has nothing to do with hard facts but everything with things like my turf and your fault.
Parties have their preferences on availability confidentiality integrity.
With a different set of requirements a diffrent technical solution is likely the result. The quality and cost is not always applicable for all.
🤔 A Clear decoupling is needed: machines services and "applications".
The daily stand-up
Knowing what the colleagues are doing is important with a shared business goal.
The implementation of a stand-up can be brought in mandatory. I would assume sitting in each neighbourhood and doing that during working on items, would be sufficient.
From common ground in a technical approach there is something strange going on:
Forced is using hyped modern technologies although there are bleeding edges not solved well.
The bleeding edges are not marked to solve and avoided for the time being but are a trigger to get in more modern technology with bleeding edges.
Asked is a the keep it as simple and cheap as possible, lean agile.
⟲ P-3.6.2 Maturity fundaments processes
👁 First line, second line supervisors
Looking for the cyber/administrative physical equivalent of who accountable for the value stream flow.
The hierarchical implementation is easily missed. These equivalent is missing. The awareness of a values stream is also missing.
The result of strict control management.
What the frustrations are, is best shown by infographics.
Safe
Sometimes you get a feeling having seen things before. Just different words being used.
In this case Scaled Agile Framework
The Fate cartoon makes it clear.
Three layers strategy, tactics, operations are there.
The development stages similar to the blamed waterfall approach.
Missing is a focus the core value streams.
Less
This is like operating an assembly belt line, not the real innoviation or improvement.
The reason: missing the business core process environment, values streams.
Most Hoshin Kanri documents that I know cover one year. This is usually a good duration, since one year allows for quite a bit of improvement activity.
This duration is also long enough to see the results and review the outcome.
The fit with the SIAR model and PDCA DMAIC is far to nice.
It solves: "who and why" going from "knowledge" (Jabes stage proposals backlog) into initiating activities.
Like the “normal” Hoshin Kanri, this document is done at different levels in the hierarchy, starting with the top executive.
These are named rather straightforward as top-level matrix, second-level matrix, and third-level matrix.
The solution of the PDCA gap is:
Product managers should report, give feed back information on the operational missions.
Product managers should report, give feed back information on the change & innovation missions.
⚒ P-3.6.4 Maturity of journeys
New journeys to enjoy.
In the agile world, using the scrum syntax, the work is decribed as a "customer journey". They can be never ending stories.
At some time "no work" is the objective goal, going for a private journey, better described as holidays.
To be repeated predictable over and over again. Not really boring wiht this kind of feeling.
It is a holiday picture made at Lakka Paxos Greece. The transport and sleeping place being the place at home in the right corner with the colored fancy fish in the aft.
During the journey doing "sprints" by going from one place to another.
The story in the gateway
I used this picture at the end of chapters, intention:
◎ following a logical sequential order.
This picture is personal (holidays). An entrance and exit of Monemvasia, laconia Greece.
Being both, the single pathway (the name in greek) it is unclear whether it is the start or an ending.
⚖ P.3.6.5 Short checklist floor impediments
Need having solved:
❌ ✅ Product process line mission status PDCA feed back.
❌ ✅ Running the alignment to security and other regulations at the shop floor.
❌ ✅ Running the processes by well defined instruction at the shop floor.
These are to be understood solved and managed by management at the high levels. This can be measured by maturity metrics.
The usual situation is: none of them is in place. Worse, there is even no awareness, CMM level-0.
⚒ P-3.6.6 No followings steps
retrospective
Going trough all this again, some experience from the paste are resurrected:
The get-away to technology as a solution for what is not well understood.
Parody stories, cartoons for what is perceived to be not going well.
The switch to how to improve something is a np-hard problem.
Transforming the way of working is a goal on its own. At least that is my personal experiences.
A very normal seen situation:
A figure: 
❶ Shared: 
❷ Non-Shared: 
He had added more programmers to a project falling behind schedule, a decision that he would later conclude had, counter-intuitively, delayed the project even further. 
.... 
Using an inverted pyramid is not new.
Parties have their preferences on availability confidentiality integrity. 
It is a holiday picture made at Lakka Paxos Greece. The transport and sleeping place being the place at home in the right corner with the colored fancy fish in the aft.
During the journey doing "sprints" by going from one place to another.
