Skip to content

Challenges when demoing / training / pitching complex systems

Over the last few days, I’ve been in a few vendor demos, trading partner reviews, product pitches, and project discussions, all reviewing complex systems or processes, and tools / software / services to help out. Some important, common, and somewhat random issues kept popping into my mind, all about trying to have a discussion about complex systems / interactions …

  1. Always be mindful that if something was easy, we probably would have done it already. Be alert for things that are conceptually clear and straightforward, but tough to actually automate – like pivot tables / aggregate queries in SQL data bases, or the concept of “clean” data, matched up from multiple systems.
  2. Be very careful when using common terms for specific meanings. A classic case – in many organizations, there can be multiple definitions of the word “customer” – make sure everyone knows specifically who we are talking about! Also, when your potential trading partner (or their implementation team) is talking about “customer”, they are probably talking about you, not the folks you sell to (who you think of as the “customer”).
  3. Some design insight – build for batch processing. Trading partners typically interact via a web interface – and the tech team likes to take lots of time to show how nice and user friendly it is. Problem – if/when we want to do orders / transactions at scale, we’re gonna want to use EDI or XML. Ya gotta be ready with the batch process right away … when designing systems for your potential customers, make sure you have a batch mode.
  4. Everybody wants to streamline their own business process by pushing the work to someone else. Sooner or later you’re gonna have to get the other guy to accept responsibility for getting the work done, or else you won’t be able to claim the benefits in your business case!
  5. A critical element when talking about projects between partners and/or internal groups – must be clear on requirements, basic business process, and scope. It’s not a meaningless exercise to drive for a decent level of documentation for this stuff – gotta be clear, especially when time commitments and money are involved. Also, you need to understand critical assumptions, like information / data availability, rules clarity, resources to do work / provide information, and time to implement.

This Post Has 0 Comments

Leave a Reply

Your email address will not be published. Required fields are marked *

Related Articles
Complexity Buzzword

Navigating Buzzword Overload: Complexity

Complexity means different things to different people in different conversations. Are we trying to simplify a process? Complexity is bad. Understand a supply chain? Complexity is good. Don't buzzword your initiatives with "complexity" until you get a wee bit more specific.

Read more

An Author’s Journey – The Editor’s Harsh Bright Light

Second in a series of articles on the creation of Don’t Think So Much. Exposing yourself to the unbiased eye of your editor will be a humbling, but super valuable, experience.

Read more

Fighting over Amber Boxes

Change is a natural part of the Digital Transformation process and nothing to worry about – as long as you don’t get too caught up in the drama of your Preferred Point of View.

Read more