Automation of a Process Within Digital Transformation

See AMP Version

Here are a few considerations for the automation of a process within Digital Transformation.

In general, a digital transformation plan will be a multi-stage process that will affect many aspects of the organization.  For example:

– Implementing or replacing a CRM

– Implementation or replacement of an ERP

– Implementation or replacement of a management system

– Automation of a particular process through custom development

– Creating a Data Warehouse

– Implementation of a platform or security layer

Your transformation plan may not consider all of these aspects, each organization has its own budget, priorities, capacities, etc.

In our last post about digital transformation, we identified 9 considerations in replacing your CRM and we ended by indicating that at Analystik, our role is often to automate business functions following the creation of an opportunity.

 

The true nature of process automation

In this post, we’ll look at an organization that has moved its CRM to Salesforce and now wants to automate a specific business function; in short, to meet a specific business need.

Once again, there are several elements to consider in this operation:

  1. Who will be the users of this functionality?
  2. What links will be required with existing systems?
  3. The size of the feature?
  4. Backup of data
  5. In what technological environment should the development be carried out?
  6. Should the functionality be available in mobility?
  7. Does the functionality access sensitive data?
  8. Security management

 

Premise for the automation of a process

To detail each of these points, let’s take the example of an organization that wants to automate the functionality of issuing a letter of offer for the financing of a piece of equipment.

Downstream of this transaction, an account had been created in Salesforce and two contacts have been associated with this account. An opportunity is now created in the CRM for this customer and some financial data is entered (so the opportunity module of the CRM has been customized to the needs of the company).

The customer verbally accepts the representative’s proposal and asks for a financing proposal. In order to make this request, new data must be entered, some of them in the letter of offer generation module and some of them in other company systems.

 

So, let’s detail the elements listed above:

1.      Who will be the users of this feature?

This question is important because we will not want to buy additional CRM licenses for users who would only use the letter of offer generation module.

If these are the same users as the CRM, then it must be determined whether the CRM’s role and permissions management capability is sufficient to control access to the various sections of the functionality to be developed.

 

2.      Necessary bridges with existing systems

Interconnectivity with existing business systems is an important consideration especially if we have opted for a CRM Cloud solution that is outside of the organization’s IT environment. Bridges must be created with the enterprise systems and according to the security rules in place, these bridges will not always be easy to build.

In our example, we need to enter financial data into one of the enterprise systems in order to obtain a credit rating.

Once the letter of offer has been accepted, the data will also need to be transferred to another system, which is responsible for managing the loan.

The more recent the business systems are, the easier it will be to create powerful and secure interfaces. Unfortunately, this is not often the case and the development of “bridge connectors” can be difficult.

 

3.      The size of the feature?

The purpose here is to help us determine where and with which technology the new feature should be developed.

In our example, the requirement is the generation of a letter of offer, in contrast, the vision is the increasingly comprehensive automation of the financing process. So, the size of this functionality will tend to become larger and larger.

 

4.      Backup of data?

In point 2 above, we have indicated that some data must be entered, others must come from the enterprise systems.

The amount of data that will be required, the vision of the functionality to be developed (size) as well as the security required for some of the data will influence the choice of the data warehouse.

Many organizations save data in CRM without really analyzing this aspect too much. This is a big mistake because despite the great flexibility of a CRM, it will never provide the same power of as a database like SQL.

In our example, considering the vision and the amount of data required, you will understand that a database independent of the CRM was favoured. In this case, an SQL database “on the premises” but which could just as well have been an SQL Cloud service.

 

5.      Within which technological environment should the automation of a process be carried out?

– Directly in the CRM or in proprietary code of the company

If the functionality to be developed is “glued” to the CRM or if it is a customization of the CRM, the choice is easy to make; the functionality is developed in the CRM.

On the other hand, as we mentioned earlier, too many companies undertake major developments in their CRM and become “prisoners” of it and sometimes even of a version of it.

You will understand that in the case of our example, the choice was fixed in advance for several reasons:

– The vision of the functionalities to be developed will be potentially great

– The organization does not want to become a prisoner of its CRM and its future developments.

– Critical data must be safeguarded

– In time, more users than those who have access to CRM will be needed.

Even though the CRM is Salesforce, the organization’s IT environment is Microsoft, it is imperative to develop proprietary code that belongs to the organization with technology that allows for future evolution and whose specificities will not require “tricks” to be programmed.

 

6.      Does the functionality need to be available in mobility?

Of course, today a lot of applications are Web-based and for many, a good Web application will also be Mobile. This is indeed true for a simple application that manipulates little data and does not have complex business rules.

In our experience, in order to properly meet “mobile” needs, it is often preferable to program only the features that really need to be mobile, so as to provide a good customer experience for both the Web user and the Mobile user.

 

7.      Can the functionality access sensitive data?

Functionality that needs to handle and store sensitive data, such as a Social Insurance Number, must be programmed to higher standards, its development will not run the same way.

Do we want the data to be encrypted, within the database? During transfers between the database and the user’s screen? Will this data be automatically erased for a client that has been inactive for several years? Who can have access to this data? With what rights?

 

8.      Security management of the process

IT environments are becoming more and more complex and we often find hybrid environments at our customers’; “On the premises”, “Cloud”, “Web”, “Mobile” or “Windows”.

We’ve all heard about stolen data in recent months, and this in high-profile organizations.

Security is now much more than a good architecture of the login/password mechanism and good management of roles and permissions.

Security management must be found at all stages of the software development process, from requirements definition to deployment of the solution.

At the same time, we want to make things easier for users; we will not want a user who has just “logged in” to his CRM to have to relog to perform a function outside of the CRM.

Nor will we want a smart guy to manually enter a URL address to access a feature that he would not normally have access to if he had been in the application.

Nor would we want to open the firewall of the mobile application that wants to retrieve data from enterprise systems.

These are just a few examples. The necessary level of security in the organization will dictate the “acceptable” risks and impose limits on the data or functionality that can be exposed.

 

Conclusion

Once again, the 8 elements covered in this post are only a preview to get you started on your digital turn. Hopefully, this will allow you to ask the right questions to the various people involved in your project.

 

Happy Digital Transformation!

Leave a Reply

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