It is very important to consider how Kashflow and eLink Lite are going to be used together. There are several possible approaches:
- All data is entered in Kashflow and then mirrored to eLink for reference
- All data is entered in eLink and mirrored to Kashflow for reference
- Certain types of data are entered in eLink and mirrored to Kashflow, and all other types of data are entered in kashflow and mirrored to eLink.
- All types of data may be entered on both systems and mirrored to the other system, (the free-for-all approach).
Why is it important to consider the approach to be used? Simply because a free-for-all approach may lead to synchronisation difficulties that may well not be resolved in a way that is desired or expected. In a free-for-all approach, it is quite possible to anticipate a situation where problems will arise. For instance, suppose Customer Fred’s address is updated in eLink and at the same time his Phone number is changed in kashflow. What happens when the data is synchronised? The problem is that the address phone number are part of the same customer record, and it is the customer record that is timestamped. So, when we synchronise the two systems, one record must win over the other, causing a loss of data. So, after synchronisation, either Fred’s Address change will be lost or his phone number change will be forgotten. Obviously, this is a highly undesireable situation. The way we avoid this sort of issue arising is to make sure we understand the need to use the system in such a way as to avoid such dangers. To this end, it is appropriate to choose some sound working practices and ensure these are maintained. The optimum solution will vary from business to business. Here are some potential scenarios:
Scenario 1 – Accounts-led Data Entry
In this system, the organisation enters all its data through the accounts package and allows it to be mirrored to eLink for analysis purposes. The main purpose of having the two systems in place is financial – to manage customer and supplier accounts.
An organisation that uses this type of system would, perhaps, be led by its finance department handling most interactions with customers and suppliers in terms of billing and payments. Other customer relationship issues are considered of secondary importance.
Benefits – there is no likelyhood of any data being lost due to data synchronisation issues. The Kashflow data is seen as the master copy of all data. The eLink data is merely a copy of the Kashflow data, used for certain specialised purposes. Another benefit of this approach is that users are essentially working through one interface (the Kashflow interface), not needing to use the eLink interface.
Drawbacks – it is difficult to use the CRM to manage customer/supplier relationships using this approach. While this approach may seem sensible for accountancy purposes, it will have a major, negative impact on the ability to use elink to its full potential
Scenario 2 – CRM-Led Data Entry
In this system, all data is entered through eLink, and synchronisation causes that data to be propagated to Kashflow. In this system, the focus of the system is to support customer and supplier relationship management. The financial side of the system, whilst very important, is secondary.
This approach is desireable for many businesses who allow the gathering of financial data through the day-to-day operation of their business. The financial data is passed to Kashflow for accountancy analysis and for determining financial status, VAT, end of year accounts and the like.
It is likely that organisations who work with this type of system are arranged such that the people who interact with customers in the conduct of the business of the organisation will also be handling the billing and accounts side of the operations.
Benefits – Again, this approach avoids problems of data synchronisation. It also harnesses the power of the CRM system to manage customer and supplier relationships. In this case, users only need to interact with the CRM interface on a day to day basis, the accounts system sits in the background gathering financial information for future operations.
Drawbacks – It is not possible to separate financial information from Customer Management Information, so this approach is not ideal for businesses who wish to avoid disclosure of financial data to their (non-finance) employees.
Scenario 3 – Departmental Division of Labour
In this scenario, we envisage a careful separation between the business operations of the organisation and its financial operations. So, in this scheme, one department (the service department) is responsible for gaining customers and interacting with them in order to deliver the products and services to those customers, and a separate department (the finance department) is responsible for billing those customers and taking payment.
In this system, the the service department interacts with eLink and the finance department interact with Kashflow. In order to separate the data, it could be decided that Customer and Supplier records are only generated by the service department. They can also generate quotes and invoices, but have no interest in payments etc. The finance department needs a copy of the customer/supplier contact details along with copies of the quotes and invoices generated in the service department, but had no need to modify these records (under normal circumstances). Furthermore, the finance department retains all details of payments made and overall customer account status.
Advantages – It is possible to determine a clear division of labour between the two departments.
Drawbacks – neither department has full access to all data, so questions relating to particular parts of the data have to be referred to the appropriate department.
Small Businesses
The above examples sound as if they are aimed at larger businesses, where several departments are involved in the business operations. However, similar issues exist for small businesses. A one-man-band can still make choices about how to organise themselves. He or she can decide which system they want to interact with on a daily basis. Some may choose to try to keep the CRM for customer relationship management and the Accounts for financial management. Others may consider it painful to need to access both systems every day, and so choose to enter all their data on one system and allow it to propagate to the other.
Initial Setup Considerations
It is unlikely that a particular business seeking to use this eLink/kashflow integration package will start using the system from scratch with no preexisting data. The problems are not too great if they have one of these two systems, and decide to link them together. But if a business is already using both systems, there is likely to be a lot of overlap between the data in both systems. The trouble with this is that the data in each system is likely to be partial. For instance, eLink may hold complete customer address data, but Kashflow could hold customer names only. When merging the two systems, it would be very easy to end up with duplicate records for each customer. Some careful consideration is needed as to how these problems can be addressed and overcome.
Having said that, once the initial integration between the two systems has been established, there is no reason to allow the previous arrangement to dictate the current working arrangement. It may also be tempting to stick with what is already known, rather than change to using the alternate interface. It is recommended that the choice of interface is made for business efficiency reasons rather than for reasons of avoiding a learning curve. But the important thing is to recognise there are choices to be made, and to give time to evaluate and make informed choices.
