Blog

Case management

Getting support – email vs portal

It may be better to have a mix of channels, including email-to-case, whilst nudging people to the portal channel

The arguments are well rehearsed. It’s better for people to use a portal rather than email to get support, right? Well, it certainly makes sense from the support organisation’s point-of-view. Good knowledge articles should deflect some cases. Forms capture all the data needed to complete a transaction reducing back-and-forth and errors. Chatbots can reduce the load on the telephone and human chat channels.

However, in my experience, some of those people seeking support do not agree… at least at first. This can be especially true for third parties you provide support to like customers, suppliers and former employees. They may be reluctant to register for portal access to ask a “quick question” they previously got answered by an email.

After investing in ServiceNow or similar product, it’s tempting to kill those shared mailboxes. It may be better to have a mix of channels, including email-to-case, whilst nudging people to the portal channel. You will be more popular with the change management team (although those maintaining complex email-to-case rules may grumble!)

Process

Documenting processes

Think beyond swim lanes

Co-authored with Rhys Williams

It’s one of our favourite parts of the job. Arriving at a new client who are about to re-engineer their processes, it inevitably comes to asking how thing get done. Nowadays few admit to having no processes, although you still get some hold-outs! Typical answers include, “we have processes, but haven’t written them down yet”, to, “we had some consultants in last year to capture these. The output is somewhere on the share drive” (possibly gathering electronic dust).

Understanding how clients capture, implement and update processes gives a good insight into their operations. It’s worth noting that software-as-a-service applications have changed the relationship between technology and process. In the on-premise ERP world technology was sometimes customised to fit processes, with SaaS the application often informs process design.

Process documentation sometimes begins and ends with flow diagrams (swim lanes) – the visual representation of who does what and when. Although these are important, it can be beneficial to create corresponding narrative documents. These expand and clarify not just the individual process steps, but also the business context of the process, the process entry and exit points, etc. For example, an HR process narrative may include discussion of the circumstances that determine whether the recruitment or transfer process is used. This narrative is particularly important for process steps as flow diagram “boxes” limit the number of words practically available.

In our experience the discipline of narrative creation facilitates more robust processes and provides a baseline for other documentation, for example related to scenarios, testing and training. Narratives also allow readers without deep operational backgrounds – such as managers – to understand the process and their responsibilities fully.

SaaS

SaaS vs On-premise ERP

Software-as-a-Service application deployments place different demands on the project team than on-premise ERP system implementations

On-premise ERP systems are typically implemented using a waterfall approach. Significant effort is placed on agreeing business requirements up-front before completing system design, build, test and deployment. Like a waterfall, the flow is one way; late changes to business requirements can be prohibitively expensive to accommodate. It also means the business has to sign-up to some system functionality before experiencing it. Although a good project team can mitigate the inherent risk, some stakeholders only see the system at user acceptance testing.

SaaS applications lend themselves to a more iterative approach. There are no database or application servers to stand-up as the vendor provides the infrastructure. With little or no lead-time SaaS vendors can make a pre-configured version of the system available to demonstrate its capabilities. Many also provide “best practice” default configuration. This allows the project team to put the business in front of a prototype early on the project. There is no customisation – as an ERP practitioner would understand it – in SaaS deployments. Instead, changes are quickly deployed via configuration enabling iterative improvement of the prototype with the business.

All this demands a different approach from the project team and wider business. The project team needs to deal with evolving requirements as the business understands the art of the possible. Sometimes the project team have to help the business adapt their way of working to the technology (instead of adapting the technology). To some ERP purists this is sacrilege, but the “throw money at it and customise” option is simply not available with SaaS! Given the iterative approach, the business needs to be available throughout the project.

SaaS deployments, like ERP implementations, often take place in the context of a wider programme that involves organisational change, business process improvement, etc. Programme managers should remember the SaaS vendor, or their deployment partner, will have the expertise to deploy the application, but may not have the inclination or competence to help with the wider change. The “client-side” team composition should account for this.

Aligning the speed of the technology stream to other streams can be more difficult with higher-tempo SaaS application deployments. Understanding the maturity of client processes, including how well these are consolidated across a complex organization, can help the programme manager agree realistic plans with the business sponsors and deployment partner.