Do you agree with the quote: "Smart people make smart processes."
I've seen plenty of smart people make poor process. Especiailly with technical people, I often see these smart people create unessecarily complex process that is difficult to manage both on the software side and business side. So I guess you could say I disagree.
Smart people can make smart processes, if those people explicitly capture in those processes WHY processes today work like that. Thus changing of those processes to follow quickly-changing business becomes rather straightforward.
Smart people love the challenge of complexity often making even the simple complex which is designed to retain control......? Fact is process is simple step by step working towards achieving individual or collective outcomes. Good people given the opportunity to contribute their experience and ideas can now help to make good processes; the start of a new journey of good people being empowered.
Does raise a question what is a "smart" process? To me it is where a process can recognise past decisions and actions which dynamically can present the next appropriate steps. Such capability is built by clever people with technical skills to be used by good business people. Might take "smart" people to think of that as a something to work on....?
Mapping our a process, putting it in-line, getting users to piano-play it, putting in some obvious and at times not-so-obvious improvements gives an organization a foundation.
Hosting BPM templates\instances in a run-time environment that accommodates deviation away from the "best practices" where appropriate (subject to goverance), gets an organization into the competitive advantage zone.
You don't need "smart" people to do this.
I have met many "smart dummies" - I remain convinced that my two german shepherds were a lot smarter than most people, including me and my wife.
Who among us can get two-full time servants to attend to their every need/desire 24 x 7?
Slightly off topic, people working at the strategy level can use a lot of help consolidating knowledge and putting that knowledge to good use in deciding how to dynamically allocate corporate resources.
No point optimizing processes when the strategy is not leading the organization in a good direction.
The link between Big Data and Competitive Advantage is worth exploring
Smart people make smart processes, no doubt. The operative word being 'people', multiple perspectives are key to a good process. Question is: are they being smart about bringing it all together? I've seen that done well and...not so well.
There are three vitally important components for successfully implementing BPM:
• Analysis and Design– Assessing and re-engineering “as-is” processes to eliminate waste while capturing business and technical requirements into realistic and attainable objectives, specifications, and solutions (“to-be”) aligned with strategic objectives and metrics
• Program Management– Aligning strategy with solution design and human resources to guide development and on-going change management to ensure on-time in-budget delivery
• Training and Talent Development– Developing skills to analyze, design, implement, deploy, administer, and change solutions
Where there are no intelligent / trained / experienced resources you won't have deep analysis nor innovative design nor usable, tested, and scalable solutions. You won't have people who know have to manage projects (budgets, deliverables, timelines), sprints, specs, integration, etc. So it's paramount to have smart, capable people involved in projects. Team members include line of business executives, business analysts, developers, architects, and project managers. Each has specific roles and responsibilities. Together, and it really takes team work, they can transform the business.
You want stupid people to design processes, so they can be used/followed by stupid* people.
KISS - keep is simple, stupid
* stupid means they don't understand the process, have no training in it, don't care.... they just need to use/follow it
- Bogdan Nafornita
- 8 months ago
Such a simple question as to whether smart people make smart processes. What's a systems answer?
Let's do an inventory: We have (1) "person making a process" and (3) "person using a process". And we have (3) "smart processes".
What are the economics and best practices of our process system?
[b] MAKING PROCESSES[/b]-- Consider the
[u]economics of business analysis[/u].It can be very expensive to fund smart business analysts to build good processes. Except the
[u]opportunity cost[/u]of not doing business analysis for process models is probably much higher in the long run.
1.1 GOOD SOFTWARE -- Smart business analysts still need good software. Not "code-by-another-name".
1.2 GOOD DOMAIN KNOWLEGE -- Smart business analysts need to be domain smart, e.g. like understanding transportation.
1.3 GOOD MODELING PRACTICES -- Smart business analysts to model "just enough". Both under-modeling and over-modeling result in sub-optimal processes.
[b]USING PROCESSES[/b]-- Consider the
[u]economics of HR[/u].The trend for a generation to "empower employees" is based on an HR calculation that employers are paying for
[u]unused employee brains[/u]. To empower employees to use their brains is to enable smarter processes.
2.1 GOOD EMPLOYEE PROCESS USERS -- Employees with domain knowledge and training will be able to use processes effectively and efficiently. Processes are always simplified models of reality, so we are relying on human agency to handle
[u]all the edge cases[/u]that models necessarily leave out.
[b]SMART PROCESSES[/b]-- So we have good process builders and good process users. What then are the
[u]economics of smart processes[/u]themselves? Answer: That we fund the right processes at the right time and then maintain them. This means "smart process management".
3.1 JUST-IN-TIME GOOD PROCESSES -- New processes are delivered when needed, i.e. without long delays which mean lost opportunity.
3.2 GOOD GOVERNANCE -- Processes are complex; poor process management or governance means that processes degrade as effective automation artefacts.
HR research suggests that for most organizations over time, it is
[u]impossible to consistently hire people who are better than average[/u]than the pool from which one is selecting. Pick skills and geography and pay level etc. and that's it. So the question about smartness can be kind of tricky. Good management is never out of style.
[b]Process-oriented management enabled by great BPM technology is a huge opportunity[/b].
I have a hard time picturing a single "smart" person creating a "smart" process. A relevant process is one that helps businesses run more optimally. Understanding how to create an end to end smart process requires a collective and collaborative effort of all involved parties. A smart person can define the vision for a critical process, but he needs to be surrounded by other smart people to maximize each step of the way. A smart person would have a strong domain knowledge of the problems resolved by the process and how it ultimately will create business impact.
On the whole, I'd guess they do a better job than dumb people, though I admit I have little data to support that assertion.
And frankly, I've seen a ton of really,
[i]really [/i]smart people make really, really bad applications. The usual reasons include:
[list]Not necessarily unreasonable, but if your platform doesn't do this easily, you have to decide which makes more sense: to just issue those notifications every hour or so, or to spend time scripting a solution. Too many smart people choose the latter.
Overengineering. In BPM, as in life, a few simplifying assumptions can go a long way. The requirements document may state something like, [quote][i]Overdue notifications shall be issued on an exponential schedule, such that the first notice is sent after four hours, the second after two, the third after one, etc. [/i]
Lack of attention to user experience. I'll repeat something I've said many times: you know those UIs you've been slapping on top of your apps? [url="http://www.ebizq.net/blogs/bpm_view/2013/01/your-users-hate-your-e-forms.php"]Your users hate them.[/url] Smart engineers may lack the empathy required to imagine themselves as naïve end users trying to interact with the systems they build.As a result, the engineers build clunky, non-intuitive interfaces that leave their customers confused and irritated.
Intelligence is a real gift. But it's only about 3rd or 4th on the list of personal qualities that tend to lead to success. So, while being smart is certainly helpful to application design, it's ultimately not per se sufficient... unless, that is, you're smart enough to turn to people who possess those key qualities you may lack for support and assistance.
I can quote a lot of experiences to the contrary: a bunch of incredibly smart people over-engineering basic processes because they must use "Turing complete" tools (and then scratching heads at the ensuing complexity). A bunch of relatively average people designing, over a few months, a very complex purchasing flow, with coordination of multiple instances via signal payload monitoring in order to emulate very complex purchasing cart settings.
I'd say that being smart is not enough to act smart.
This holds true even more when you factor in the rest of the cognitive impairment situations: tired, hurrying, distracted, angry, frightened, eager, highly emotional people can't think straight on such moments.
It might be better stated as “Smart people are bored and overcomplicate things to entertain themselves”.
I have been designing processes and writing software frameworks for dynamic processes for almost a decade now and I can say without a doubt that smart people are frequently bored. This manifests in overly complicated processes as well as overly complicated code. I think this boredom goes unnoticed in many organizations and you end up with mammoth endeavors that fail after a few years of development with little to no adoption.
I do believe that it takes smart people to make a truly smart process though. It takes someone with the intelligence and skills to talk with people and find out how the business is currently operating so they can make improvements.
The most impressive processes that I have been a part of creating have involved layers of abstraction for the users of the process. This entails simplifying the pieces of the process that less skilled workers interact with by putting it on “rails” for them. This is also helpful for users that may only participate in a process once a year (think Business Continuity training exercises). I have found that when you simplify their interaction you increase the adoption of the process.
@Karl I agree that proper architecture solves a lot of the issues with a development process. Extensible and maintainable code are a must as the size of the application grows.
My current startup project is addressing a lot of those concerns. Low/No code solutions for dynamic processes that, in a sense, can "write programs".
- Rick Willis
- 8 months ago
If the project manager prepares a Statement of Work (SOW), builds a work breakdown structure, and publishes a timeline for a project specifying milestones and deliverables, modules can be tested as they become available and accepted/sent back, with the result that projects do not so easily go "off the rails".
Object-oriented programming allows programmers to focus on building classes that are re-usable and extendable.
Debugging time can be greatly reduced by embedding pre and post conditions at functions (Dr Bertrand Meyer's "design by contract").
Then, some developers have mastered writing programs that write programs with obvious positive outcomes.
Good application systems have good architectures.
@ Rick. Good initiative
OK, the whole
[u]"smart people" meme[/u]could be addressed directly.
The idea of "smart", correlated with intelligence but not the same (i.e. captured in the idea of "street smart"), is fraught with pitfalls.
In my note above I highlighted the "economics of smart" (via HR).
[b]It's not a sustainable strategy for most organizations to depend on or to hold themselves hostage to expensive smart people[/b]-- or people who think they are smart and are
[u]good at signaling smartness[/u]. This doesn't mean that there aren't specialists or that some people are not smart in ways that are very important for the organization. But it is saying that the organization should be
[u]robust against the dysfunctional smartness[/u].
[list][/url]", concerning the smart hires by U.S. Secretary of Defense Robert McMamara to run statistics on the conduct of the Vietnam war is a good example of smart people doing stupid things.
David Halberstam's "[url="https://en.wikipedia.org/wiki/The_Best_and_the_Brightest"][quote][b]The Best and the Brightest[/b]
[list]". The article argues that math is and always will be an elite activity. One could say that this article is a counter-example to the McNamara example; I would argue however the opposite, that the fetishization of smart isn't a very good idea. (At the same time of course, we can honour marvellous achievement in math or any domain.)
Interestingly, concerning math, typically held to be the domain of the smart, just this month Scientific American has an article on how mathematicians are overselling the idea that "[quote][b][url="http://blogs.scientificamerican.com/guest-blog/mathematicians-are-overselling-the-idea-that-math-is-everywhere/"]math is everywhere[/url][/b]
The whole smart thing shows up in current political debacles too. Without reviewing issues that are currently showing up around the world, I note that part of the debate concern the downsides of smart. There is a fear that
[u]smart is too often stupid, and too often correlated with rent-seeking[/u].
Whether in politics, government, non-profit or business, solid organizations can thrive with good management. And good managers know that sometimes you need to
[u]hire specialists[/u]. BPM technology is an amazing technology that can help all of us be the best we can be and has a key role in helping ensure that organizations comprised of every type of person are successful.
Smart processes are for Dumb people
Dumb processes are for Smart people
While it sounds a bit crass, there is some truth to this.
And everyone is relatively dumb outside their area of experience and training. Sure some people can learn much faster and retain more than others. I imagine a work environment which is dynamic and which all actors are moving through arcs of learning and experience.
- John Morris
- 8 months ago
What is a smart process?
1) If it is just well designed and optimised process, then it is not smart. Does this make the person who performed this design/optimisation activity a smart person? Probably not smart, but definitely a highly competent designer of business processes.
2) Would not a process to be called a smart process have to be self-aware? Well, the individual who could put such a process in place would definitely be "smart". Imagine a self-aware process, presumably this would also mean that the process is self-organising, as it would have at adapt to both intrinsic and extrinsic environments variation. This would be the holy grail of all processes.
It might be interesting to evolve a maturity model for "self awareness" - the processes we work with currently know what all of the plan side steps are, how they are linked, who needs to perform them, what instructions and forms are needed at each step, They know which steps have been completed, skipped, are current, are not yet current.
What they don't know is when steps should be performed (putting durations on steps is pointless if you allow users at run time to insert ad hoc steps at any template instance and the second reason is there can be important delays between steps because of holdups and because staff may be working on many Cases at one time.
The processes know via pre-post conditions whether processing can be engaged (one thing to have a step become current, another thing to allow processing to be initiated by testing whether the data needed to effect a calculation is present and within acceptable ranges).
For sure, processes are not very aware of the next ad hoc intervention. (what, who, when),
I am interested in data mining for the purpose of providing advice and assistance to users on when repeat ad hoc insertions should be built into a process, or based on skips, when a step should be removed from a process. I
am interested in having decision support available at branching decision boxes so that users can see that, for example, 40% of the time other Cases went this way, 60% of the time other Cases went that way).
Lots of interesting areas to explore !
- Page :
However, you are not allowed to reply to this post.