Resolved
3 votes
Business agility is essential for survival in today's marketplace. So what is the most important factor for achieving business agility in an enterprise?
Tuesday, March 04 2014, 09:28 AM
Like
1
Share this post:
Responses (13)
  • Accepted Answer

    Tuesday, March 04 2014, 09:37 AM - #Permalink
    Resolved
    1 votes
    In terms of corporate culture, the fostering of an environment in which people are encourage to think -- and in terms of technology, a system that allows the ready communication of those thoughts to other thinking people for collaboration, consideration, and action.
    The reply is currently minimized Show
  • Accepted Answer

    Tuesday, March 04 2014, 09:40 AM - #Permalink
    Resolved
    1 votes
    Hope you don't mind me taking a layup with this, but David Linthicum just wrote a whitepaper on this, "Real-time is Agile", which is available on our website - http://enterpriseweb.com/category/resources/ In general, agility describes an ability to respond to an environment (threats or opportunities). All life is inherently adaptive - we secure new niches or fail. Standing still, stasis, is actually death. All human organizations are inherently agile as well - look at startups. The challenge is the inflexible structures that are built up as a Company grows. The business wants operational systems for convenience, but doesn't expect to give up agility as part of the deal. Agility in the 21st Century means the un-coupling of the automation technology of the 20th century to allow for dynamic/adaptive organizations.
    The reply is currently minimized Show
  • Accepted Answer

    Tuesday, March 04 2014, 09:44 AM - #Permalink
    Resolved
    2 votes
    In my mind, agility = flexibility + design coherence. The key to secure sustainable agility for the future is being able, as an organization, to effectively conceptualize and formalize your business model (the motivation framework, the enterprise architecture, the organizational design). If your business is able to do this in a consistent manner, then it will be able to create the ultimate agile position - it will naturally mutate itself to adapt to new markets / new disruptive technologies / new commercial paradigms. The ability to out-innovate your own previous business model is the ultimate agility. Most businesses die or become irrelevant due to their inability to mutate their business model (see: Kodak, Nokia, Blackberry etc), not because they are incapable to respond in real-time to new products, new competitors.
    • Keith Swenson
      more than a month ago
      Formalized models and design coherence is precisely how we ended up with organizations that are unable to change. This is the opposite of agility.
    • Bogdan Nafornita
      more than a month ago
      Keith, please allow me to clarify. Formalization and design thinking, when done right, are the key driver to one's ability to change.

      Let me give you one example:

      A start-up is by definition, extremely flexible. Does this mean it's agile? Not necessarily. Change without purpose and clarity is useless and may even be fatal. A flexible start-up can die extremely easy because it may not be able to systemically understand what, where and when to change.

      By contrast, a start-up that gets build by following the lean methodology will be able to systemically incorporate outcomes of experiments to seek value and to enhance its business model. A lean start-up can therefore more successfully pivot a business model simply because there is a systematic process for business value discovery.
    The reply is currently minimized Show
  • Accepted Answer

    Tuesday, March 04 2014, 10:04 AM - #Permalink
    Resolved
    1 votes
    Processes need to have monitoring and corrective action, but agility is that and more. So the Process Owner needs to be looking at the process today and the process going forward, and employees doing the same. Data is key. Process and customer data is key for seeing what is happening today and industry and competitive data to recognize what is happening in the market place and knowing when to take action there. It implies the knowledge of what is needed (based on customer, market, and current execution) and then an ongoing process to decide and take action. And to be agile, the action has to follow quickly.
    The reply is currently minimized Show
  • Accepted Answer

    Tuesday, March 04 2014, 10:14 AM - #Permalink
    Resolved
    2 votes
    I'd love to say the answer is "It's all about great technology. Wanna buy some?" The truth is that Business Agility is driven by culture and politics far more than a technology choice. When I've talked to our customers about their journey to an agile enterprise, three topics usually come into play. Business and IT must step into each others roles. Forrester has reported that by next year, over half of IT projects will run from outside of IT. This is a good thing, but it means that business people need to take the initiative to think strategically about technology. Successful business people will understand that technology is essential to implementing and changing their business strategy, and will know enough about technology to make it work. Successful IT leaders will understand the business value of what they are doing beyond just "keeping the lights on." This cultural shift is often best implemented by real organizational change, insuring that IT and business are aligned to support customer needs and agility, rather than traditional silos around front/back office or channels (web, phone, etc.) Accept iteration, which means accepting the need to try (and occasionally fail). Waterfall project methodologies are built around "getting it right." Moving to an agile mindset means accepting the fact that the very definition of "getting it right" is changing far faster than traditional project life cycles allow. Whether a company choses Agile or SCRUM or XP-based methodologies is less important than coming to accept iteration. And that means trying things (new process models, new customer approaches, etc.), monitoring them and changing in real time. And it means learning that you don't need all the answers up front, and that the first thing you try may not be the right thing. And that's okay. For many organizations, this means fixing the way many projects are funded, balancing the need to iterate with the demands of trying to get all the requirements and ROI calculations decided before the project can be started. Think big, think broad. One of our customers said at a recent roundtable, "When you live on the cow path every day, its very easy to want to repave it." Becoming an agile business means learning to think more broadly about your processes. All the iteration in the world won't change the game, unless you put the end-to-end process on the table and think deeply about how to change it. Increasingly, that means taking an "outside-in" approach and learning to think about processes from a customer perspective, something that most organizations find very hard to do. But if you can combine that type thinking, with an iterative approach that allows for trial and error, and business and IT leaders who understand each others needs, then you can start to build a truly agile organization. And if you want do that, I know of some great technology to enable you. Wanna buy some? ;)
    • Keith Swenson
      more than a month ago
      I agree with the points, except one important qualification: if you have separate roles for "IT" and "business" you will always have unnecessary delays, and unnecessary iterations, in the cycle. To achieve real agility, you need to remove the distinction between "IT" and "business". There must not be a "design time vs. run time" distinction. As Dave points out, it is all "real time" instead.

      This might not always be achievable: some systems simply have to be programmed by IT people. In that situation the best you can do is what you suggest. However, such an organization will only be a little bit agile. True agility will require a system that does not require a difference between IT and business.
    • Don Schuerman
      more than a month ago
      Agreed, Keith. The fact is most organizations have separations between IT and Business, and I don't see that cultural distinction going away. I don't see IT and business as equivalent with design time v. runtime. I think both IT and business are stakeholders in every application, and the more they can learn to think like each other, the more agile an organization will be.
    The reply is currently minimized Show
  • Accepted Answer

    Tuesday, March 04 2014, 11:48 AM - #Permalink
    Resolved
    1 votes
    "Agility" in business needs People who are "empowered" to just get on with their job without being "over managed" and restrained by old IT systems! So how is this achieved? Enlightened management who see that it is their people who make the business and ensure they are supported by real time information that helps people make good tactical and strategic decisions. A change of culture away from the fear of change to one where change is encouraged will be transformational in achieving such “agility”? This requires user confidence in the supporting “adaptive” software which needs to deliver not just the real time "monitoring" but ability to change as business users recognise better ways to achieve the desired outcomes. Don is right saying "Business and IT must step into each others roles" the current Gap between business and IT needs to be closed. This is where supporting BPM Platform software with in built adaptive capability will deliver just that by putting required business logic and practice into the hands of the business without need for coders. IT will remain in support to deliver securely and of course help set up "orchestration" as required the data from the legacy "mess".
    • Keith Swenson
      more than a month ago
      David, I agree with you. But .... just this once! ok? :-)
    • David Chassels
      more than a month ago
      Keith
      So you now "get" "without need for coders"? Knowledge is king you should get to understand - we are still learning! And I am proud to be a founding member of the "Unreasonable Learners" see unreasonable-learners.com
    The reply is currently minimized Show
  • Accepted Answer

    Tuesday, March 04 2014, 01:47 PM - #Permalink
    Resolved
    0 votes
    Some good responses here, and also some quite amusing ones. Consider what it mean to "formalize" a business process. "Formalize: give (something) a definite structure or shape". To be a formalized structure, you need to make it explicit, and you need agreement. Nobody would consider an unspecified, unagreed process as being a formalized representation of anything. The very act of making something "formalized" is an act that prevents agility. You can not get an organization to "agree" on anything quickly. Anyone who has worked in an organization knows this. Agility can not depend upon an agreed upon structure. The necessary ingredient for agility is the permission for people to move forward on structures and processes that are not formalized. Same thing for "consistent design". Insisting that a design be consistent means not only constrains on the design, but also that there is agreement on what the boundaries of acceptable design are. An agile organization that found a new way of working that was inconsistent with the old way, would be prevented from moving forward. Formalized models and consistent designs are engineering principles that make the life of the engineer easier. Engineers tend to build machines, not agile organizations. Agility is the antithesis of these engineering principles.
    • Peter Whibley
      more than a month ago
      The reason we formalise a business process is to ensure we can repeat it. Formalised processes are the product of the agile business. Rather than viewing formalised processes in a negative way they are necessary to free employees to ensure they can continue to be agile. In a previous role we defined business agility as the ability for an organization to sense (opportunities and threats), prioritise (possible responses) and act (execution). To successfully become agile organisations need flatter organisational structures and to devolved decision making from the top of the organization to empowered employees.
    The reply is currently minimized Show
  • Accepted Answer

    Tuesday, March 04 2014, 02:29 PM - #Permalink
    Resolved
    2 votes
    I would follow the Pareto principle (law of the vital few) to say that agility is an architected mixture of “solid” parts and “flexible” joints -- example is a human arm. Do we really want an enterprise be as the arm of Harry Potter from the second film? I don’t think so. The ability to re-use / re-configure / re-mix existing models, knowledge, assets and processes together with new models, knowledge, assets and processes is the most important factor. (Note that new org structures should be generated from new processes.) Again, such an ability should be architectured as a platform for business execution. Management by processes (in its modern form as BPM+ACM) is one of the most important capabilities of such a platform. Thanks, AS
    The reply is currently minimized Show
  • Accepted Answer

    Tuesday, March 04 2014, 05:30 PM - #Permalink
    Resolved
    0 votes
    First of all, congratulations and a hearty "thank you" to those of you who made it this far down the thread. The responses above are mostly very good (not gonna pick a fight and tell you which ones weren't) but are also kind of academic. I'll try to bring it down to street level. I'm also going to take some license here and assume that, for the purposes of this forum, when we are talking about "business agility" we mean "business process agility". Want to improve business process agility? Great. Give your programmers the freedom to find work in the software industry (that is, get rid of them). Don't lock your processes into code that can only be modified through difficult, expensive, and time-consuming development. All the rest, as they say, is commentary.
    The reply is currently minimized Show
  • Accepted Answer

    Tuesday, March 04 2014, 09:23 PM - #Permalink
    Resolved
    5 votes
    Another thrilling discussion about a critical aspect of business and technology today -- and note that when I say this I'm not being ironic. The thrill is partly because there's a lurking disagreement here. Whibley, Nafornita and Samarin make good cases for formalism (my apologies for any misrepresentation or having left off anyone). The other "side" presents a rhetorical expression of "agility as freedom", a rallying cry to throw off the shackles of traditional and un-agile business. Oddly there is truth on both sides; to live is to be agile. But what has that proposition have to do with technology? The original question asked about the merits of business agility; the answer is all too often that technology, especially a technology defined by formalism, stands in the way of agility: formalisms "bad" if you will. But they really are two separate questions. Proposition: The only way to achieve agility is by more investment in technology, specifically founded on formalisms. In the same way that database formalism in the form of relational database theory freed business from the un-agile prisons of network and hierarchical database, so to will increasingly powerful formalisms make possible agile and adaptive process management. And failure to build business on formalist technology will doom us to creeping ossification and brittleness, the opposite of agile. Why? Because the only way to achieve "function 'x'", lacking the freedom of a fundamental form, is to code it. And thus you've just poured glue all over yourself. I've never quite understood the rhetorical attraction of agility, as opposed to the "mere merits of agility". Maybe it's easier to pursue agility than to master theory. But agility can hide many sins too -- one's stock broker might be considered agile while he/she churns your account for commissions. Bureaucracy is no doubt the bête noire of the agilists, but bureaucracy was originally a wonderful invention which aspired to equal treatment of all, and efficient use of resources, over the corrupt, unequal and inefficient fiefdoms of feudalism and autocracy. Bureaucracy can be well managed or poorly managed, and sometimes ill-sized. But it is fundamentally progressive when compared to what went before. Bureaucracy is a kind of 19th c. formalism for organizational design. (One might even say that "feudalism was agile", what with hundreds of years of chaos and exploitation by "mobile" armored knights.) Agility yes! But built on the science and discoveries of civilization and management science. And that means more technology and more research and formalisms on which technology is built. Process theory awaits its E. F. Codd.
    Like
    1
    • David Chassels
      more than a month ago
      John
      Very interesting I had to look up E F Codd a Brit again "invents" but goes to US! I now "get" your point but I wonder if that point has now been reached?

      Codd seems to be credited with relational connections with the database. This is what "people and process” is about? This was the basis of our research over 20 years trying to understand how to make the connection to deliver on much that is discussed in this forum. It was published last year http://www.igi-global.com/chapter/object-model-development-engineering/78620 The summary gives the basics and has evolved as we learn how the power of commoditised simplicity in software technology opens a new door for that people and process connectivity.

      On “process” Peter Keen’s book on the “The Process Edge” highlights the importance of people and process and makes the very relevant point for this debate that good processes are assets BUT only if they remain flexible – I believe we may have opened that door and intuitively supports “system thinking” by empowering people at work which is a strong theme in the discussions.

      This is all “new” to ” IT” so a big challenge and steep learning curve but it must happen as Enterprise Software remains in relative dark age whilst the rest of ICT has moved forward. It will be the “BPM” discipline/practice that will drive the change but as you say needs that technology support……I think that we in UK have created and pioneered such an E F Codd paradigm shift; ironically thinking as he must have in those early days in enterprise software?
    • Bogdan Nafornita
      more than a month ago
      John,

      "And failure to build business on formalist technology will doom us to creeping ossification and brittleness, the opposite of agile. Why? Because the only way to achieve "function 'x'", lacking the freedom of a fundamental form, is to code it. And thus you've just poured glue all over yourself"

      Thanks for speaking my mind - I could not possibly say it better.
    The reply is currently minimized Show
  • Accepted Answer

    Saturday, March 08 2014, 06:53 AM - #Permalink
    Resolved
    0 votes
    'Agility is not the technology function but a human capability only.' I wrote ten years ago in a critical piece on 'BPM business agility'. I was broadly branded as a heretic and ignoramous who did not get it. As one can read here, we have fortunately come a long way and the voices of those who propose that all processes must be encoded for a business to become agile are diminishing. Any approach that in some way describes what a business does in formulae is a formalist approach but the key question is which one. While some BPM methodology formalizes in goals, outcomes and handovers, the follow on implementations are still high-level programming, may it be BPM flow-diagrams, Dave Duggal's RESTafarian ways or David Chassel's magical mystery tour. I find the same mindset spread out over our implementation partners and our customer's IT architects. They think in input-function-output and write some formalism to implement it. That is not agile. Not the technology means are relevant, but simply whether it is used to transport the right kind of business concepts. It is the thinking that is flawed. There are even those who ask for adaptive or agile strategies which leads to ever more fuzzy and broad statements of intent rather than profound guidance. What businesses are missing today is not strategy statements and agility but solid leadership. Any strategic statement that leaves me wondering how to implement is not leadership. 'We want to be the leader.' is quite useless if it doesn't spec the why, what and how. 'We want to achieve the a 10 point higher customer service satisfaction rating by investing amount x into customer service staff hiring and training.' That is guidance. 'We will increase our ability to react to customer demand by insourcing the call center from India and empowering service agents to achive first call resolution.' That is a valid step towards agility. Agility is about people, not about technology. Yes, in modern times empowerment is linked to the right kind of software technology but as long as one has to implement too many rules, flows and procedures, agility is not going to happen. Startups are agile because they do not have these restricting software pieces but people still talk to each other. What the software can do to support human agility is to make both guidance and work transparent in real-time. Real-time is not about big-data and analytics ... that is pure rubbish. More data just obfuscates the essential. To bring business and IT together the business must be able to use the technology in their own language (defined in an ontology) and formalize goals, outcomes and handovers for each process owner (which in effect creates a capability map). I yet have to see a business, where management can actually formalize these three definitions off the top of their heads. I yet have to see a business where autonomy, authority and means are given to a process owner without further restrictions, which is far away from chaos or anarchy. And once again there goes your agility. We are unfortunately stuck in a world of ridiculous compliance needs but that does not mean that a business has to squeeze all it does into the same straightjacket. Some checkpoints, boundary rules and verifications are driven from the outside and we have to live with that crap. Be bogged down with it and their goes your agility. In MBA programs and BPM methodology today, what is taught is how to get rid of agility to allow for more illusionary predictability of numbers. The formalism is more important than the human. It is a self-fulfilling prophecy that has little to do with actually doing business and especially not with serving customers. The need for business agility comes from human needs and can only be achieved with a human response. Technology must not restrict those humans in any way but empower them in real-time.
    The reply is currently minimized Show
  • Accepted Answer

    Sunday, March 09 2014, 07:00 AM - #Permalink
    Resolved
    0 votes
    Max You make it all so complicated! There are some gems but they get lost in the noise except your last comment which sums up the key to agility? The key to actually delivering BPMSolutions (which includes ACM look forward to you rebuff on that....) is having the right supporting technology that as you say " must not restrict those humans in any way" This is what was at the heart of our 20 year R&D and work with early adopters and we are still learning. It is so simple yet handles so easily all the required business logic, simple and complex. The minute you cut new code you will create that inflexibility that has caused so much pain and cost for customers? Yet business logic supporting users just does not change and that was at the core of our research which is the start of commoditised software which removes need for custom programming. Yes maybe to die hard IT people it is a “magical mystery tour” but not half as "mystical" as IT has been to business which of course has suited the IT software industry. Well that MUST change as John put it "Process theory awaits its E. F. Codd" and I am putting down that marker now. This new BPMPlatform software is going to re-write the applications business with the focus as often described in this forum.......watch this space...our global funding and related contracts are almost in place as is our novel and equally disruptive distribution model......it is going to be fun but very painful for some vendors just as it has been for us to survive to this stage….the real winner will be the customer a true sign of product maturity…..long over due for Enterprise Software?
    The reply is currently minimized Show
  • Accepted Answer

    Tuesday, March 18 2014, 01:52 PM - #Permalink
    Resolved
    0 votes
    All good discussion around the middle where business and IT can meet - Do we define Agility as the ability to change? Or, as the will to change when necessary? To the latter, I would answer more simply and propose this is regardless of who is on-board or what the technical and cultural inhibitors are -- It takes Leadership. Period. Someone to see what needs to be done differently and to demand change - If this comes first, then there will be motivation to do all of the above that you all mentioned to make sure it can be done easier next time - achieving the former.
    The reply is currently minimized Show
Your Reply

Join the Discussion

Want to join the discussion?

Login, or create an account to participate in the forum.

Top Participants

Dr Alexander Samarin
278 Replies
29/09/2016
David Chassels
270 Replies
29/09/2016
Emiel Kelly
223 Replies
29/09/2016
Bogdan Nafornita
210 Replies
29/09/2016
E Scott Menter
182 Replies
28/09/2016