#EDI Self-Service is not only #DIY

#EDI Self-Service is not only #DIY

This week I shared news about my new mapping certification, and I think it’s worthwhile to explain the context.

Recently I demoed the self-service capabilities of the #IBM #Sterling #EDI platform for the first time, and as I was doing so, I realized that while I was well capable of explaining the WHAT and WHY, I would have been far less comfortable if asked to show off the actual HOW. So, during the past weeks I worked through an extensive hands-on training course to be able to certify myself as a mapper capable of using the self-service tooling.

I’ve always been a big fan of being able to show off how my tools work in a live and dynamic fashion. This has sometimes brought me into conflict with my mappers who were frustrated by my lack of insight into their process, when I’d ask for some mapping change that sounded trivial to me but resulted in a lot of effort for them.

For sure my transformation team should have very little concern that I’m about to embark on a new mapping career, but by having done the mapping course, I find I have a better understanding of their challenges as well as issues that customers describe to me on an almost daily basis.

More and more, traditional EDI “VAN” customers are finding it hard to staff EDI roles. Until recently, however, I only had 2 general flavors of service for them to choose from… either the communication-only VAN, where they are responsible for their own transformation, usually on-premise, or full-blown SaaS managed services where my teams take on the entirety of the effort. For many customers this proved too rigid a structure, as they may still have some deep in-house skills, just less than before and would ideally like to self-manage certain key tasks.

Receiving many requests for a middle-ground approach led us to develop a set of self-service options, that currently include mapping, API connections and codelists, and inside those, granular permissions to read, edit, create / delete configurations. This is all subject to having first completed the extensive training on how to use the very sharp tools involved. Future roadmap items include e.g. PGP key setups. A customer can choose to do the bulk of the tasks themselves, or continue to delegate them to IBM, or indeed an IBM Business Partner who may be working with the customer's staff, or a case-by-case blend of all the above.

Imagine for instance a trivial codelist update that would in the past require a ticket be logged with IBM support, then likely a conversation between the customer and support on exactly what’s needed, followed by the doing, possibly all spread over a couple of days.

Now the customer can opt to just do it, saving themselves time, effort and cost, and a dramatic productivity boost for a small piece of work, but which some customers need to do multiple times per day.

Assuming they have the resources to hand, more complex tasks like mapping could be done in the same way, and there are guardrails included in the toolkit to manage the creation, and testing, through deployment to avoid pitfalls like inadvertently generating infinite loops. Versioning also allows a user to pick up work where last left off, or to roll back changes.

?

If you’d like to learn more about our self-service capabilities, please let me know.

David White

Cloud Architect at IBM

1 年

The infinite loop problem is sometimes very hard to detect and is usually data dependent. A map may run fine with many transactions then enter an infinite loop with the right sequence of data. Infinite loops can be within extended rules or in map structure itself. The need for using AI to detect bad maps will increase as self onboarding of maps becomes more prominent.

You surely keep yourself busy Ger! ???? Thanks for sharing!

要查看或添加评论,请登录

社区洞察

其他会员也浏览了