From Sage’s perspective, Sage 200 is the end point on a migration path that starts with either the Line 50 or Line 100 applications, moves through Windows-based Sage MMS, and ends up with the modular, Windows and SQL Server based Sage 200.
With several thousand users still using Line 100, as well a significant number of MMS customers, Sage has a rump of users it would like to move upwards. It is encouraging them with the carrot-and-stick approach: dangling integrated front-to-back end processes while effectively dropping the MMS product by offering support rather than development, and morphing it into Sage 200. MMS is the stepping-stone toward Sage 200 version 4.x. Sage expects 500 to 1000 customers a year to upgrade to Sage 200.
To briefly recap the application history, MMS was the result of a project to migrate Line 100 functionality to the newer .NET architecture. Sage 200 4.1 is based on retained yet re-engineered MMS code, coupled with Sage CRM capabilities and a range of integration tools, all presented as a platform for delivering integrated front to back office processes.
When a client buys Sage 200 [4.1] they get core financials and core front offices processes delivered as a platform and integration tools to allow processes to flow from the front to the back office, said David Pinches, head of product management and R&D at Sage UK. Customers can add additional modules such as bill of materials, commercials and project accounting, plus a industry specific module for the construction sector. Sage plans to add a manufacturing module, plus extra functionality modules including payroll, asset management, forecasting and business intelligence.
Although the application is based on a set of linked modules rather than a tightly integrated suite, it aims to provide the same level of process integration. For example, a tele sales agent using the CRM functionality to manage customer call back could also access the customers’ financial status and order status and even kick off an order process, all from what would be perceived as a single application. Sage 200 enables a user to start out in one of the application modules but kick off a process that ends up in another. Previously it would have required the user to log into separate front and back office applications.
Sage is in the tricky situation of trying not to offend its installed base by forcing too much change as it moves towards a fully fledged suite and maintaining the depth of functionality of its separate applications, while also trying to appeal to new users who are asking for integrated suites. The result, Sage 200, is what Pinches describes as a software architecture designed to manage business processes.
Twenty percent to 30% of our focus is on bringing our technology into integrated suites but it does not make sense to lose the work we have done over 20 years to get [there], he said. Its strategy, therefore, is not to create a single stack but to bring modules together using web services to expose processes and enable apparently seamless process integration.
Where Sage 200 4.0 was characterized by separate products with lose integration, 4.1 is a much tighter proposition based on the core platform of financials and CRM, installed as single instance with configuration options and optional add-on modules.
