Caliach Ltd

  • Cedar House
  • Vine Lane, Hillingdon
  • Uxbridge
  • Middlesex
  • United Kingdom
  • UB10 0BX (map)

  • Tel: 01895 230203
  • Fax: 01895 230233
  • Website:


  • Paul Wilson, Managing Director
  • Chris Ross, International Director
  • Number of Employees: 1 - 20

Providing Practical ERP for SMEs

Caliach Ltd is the UK author of practical, innovative manufacturing business software for SMEs - proven in a wide range of industries since 1990.

Caliach Vision puts management excellence within reach of smaller manufacturers through an affordable, intuitive, and future-proof ERP platform.

Lower Total Cost of Ownership (TCO) is assured with simple implementation, operation and maintenance, while development is focused on user's real-world requirements rather than the latest IT fashions.

Functions available include:

  • Marketing Contact Management
  • SoP, PoP, Work Orders
  • Jobbing and Estimating
  • Shop Floor Data
  • Inventory Control, MRP/CRP
  • Product Costing
  • Rules-Based Sales Configuration
  • Multi-Currency Financials
  • Analysis and Reporting

ERP for the Small To Medium Enterprise

Caliach Vision is a state-of-the-art ERP system for managing all aspects of a manufacturing enterprise. It creates a disciplined environment in which your decisions concerning supply and demand are fully supported by fact.

The comprehensive management information provided by Vision can achieve dramatic improvements in overall business performance in small and medium sized operations.

A practical tool for day-to-day management, Vision combines comprehensive features with ease-of-use. Its class-leading user interface and integrated Internet tools create the definitive, future-proof platform for the smart manufacturing executive in the 21st Century.

Vision is also easy to support and can be maintained and upgraded without the need for dedicated technical staff.

Improved Productivity and Service

  • Better inventory management with lower stock levels and reduced stock-outs.
  • Improved customer service with better delivery reliability and consistent quality.
  • More accurate costing and secure pricing.
  • Improved productivity and better utilisation of internal and external sources.
  • Better and speedier response to change.
  • Total business condition visibility.
  • Achieves cost efficiencies in a short payback period.

Manufacturing ERP Software for SME

Manufacturing operations can be divided into two broad categories based on the mode of operation, dictated by the nature of the end product. Each category has particular implications for the implementation of manufacturing Enterprise Resource Planning (ERP) software, and it is important to identify the relevant mode(s) before short-listing potential solutions.

Discrete manufacturing operations (including single product, batch mode and mixed-mode variants) manage the production of finished goods by breaking down the composition of the product into a (usually multi-level) Bill of Materials (BoM) structure, and describing the manufacture of each node in the structure with a "process route" consisting of a (usually sequential) series of operations to be carried out at various work centres. The main characteristics of this category are that each product has a fixed defined identity with a BoM and a process route, is manufactured singly or in batches using works orders, and the time-phased introduction of materials to the production line is co-ordinated with the start of manufacture of the various nodes in the BoM structure. A sales order is used to represent customer purchase order demand, and invoicing usually takes place once finished goods are dispatched from inventory after manufacture.

Jobbing manufacturers however take a different approach - the job is broken down into various elements such as material requirements, work centre operations and other ad-hoc elements (feasibility studies, design exercises, stage payments etc). The job will typically have a start date, various material issue dates, operation timings and a completion date. Invoicing regimes often vary depending on contractual and cash flow implications. The main differences with discrete manufacturing are that there is usually no fixed product identity, BoM, or process route; therefore time phased material issues and operation timings are dictated by job elements, and work orders are not normally required. The job itself represents the customer purchase order demand, and invoicing can take place at any stage during the life of the job. The jobbing approach is widely used in sub-contract engineering, project and custom work.

SME Issues

Historically, the larger manufacturing ERP systems would cover both of the above categories on a modular basis, or would be customised to accommodate different modes. Unfortunately, smaller manufacturers have traditionally been faced with a choice between jobbing based software and discrete manufacturing software, and have often had to compromise accordingly.

As competitive pressures have forced manufacturers to diversify and offer complementary services to maintain customers, it has become unreasonable to expect them to jump into one camp or the other. This has led to the emergence of software for manufacturing SMEs that incorporate both of the above modes.

Furthermore, manufacturers should expect full integration between the modes, in material requirements planning, capacity planning, and invoicing etc. For example, if a job element demands the production of a complex assembly, the assembly can be produced on a conventional work order and then issued to the job. In the leading systems, it is even possible to design and manufacture a prototype using a job, and then automatically convert it to a standard manufactured product complete with top-level identity, BoM and process route, and even generate a new sales order as part of the process!

MRP versus ERP?

What manufacturing management system do I need?

Manufacturing management systems
have evolved in stages over the past 30 years from a simple means of calculating materials requirements to the automation of an entire enterprise. 


In the 1970s material requirement planning (MRP) was developed as a mechanism for manufacturing companies to calculate more precisely what materials they required, at what time and in optimum quantities.


Manufacturing Resource Planning (MRPII) evolved from MRP, because many companies realised that as well as the need to calculate their material requirements precisely, they also required detailed capacity planning, scheduling, shop floor control and other calculations.

MRPII introduced the closed-loop model, which uses a centrally held data file to record, monitor and report on various company activities. By comparing forecasts with actual data, companies can analyse performance and improve processes to achieve better efficiency.

CaliachMRP is Caliach's established MRPII system for managing core manufacturing activities


Enterprise resource planning (ERP) developed MRPII even further to embrace all business functions, not just those concerned with actual manufacturing. ERP encompasses materials planning, efficient production, profitability, customer satisfaction - almost every aspect of business.

ERP also incorporates the principles of global supply chain management, in which the value of every activity in the supply chain is analysed, along with the growing development of Internet or web-enabled procurement.

Caliach Vision is a state-of-the-art ERP system for managing all aspects of a manufacturing enterprise.

Bespoke Versus Standard - The Perpetual Debate


A previous primer in this series (Vendor Selection) has already identified three common sources for manufacturing Enterprise Resource Planning (ERP) software - in-house bespoke systems (custom-written for a specific application), out-sourced bespoke systems and standard packaged systems.

Concerns that can lead to a preference for bespoke applications include unique requirements not widely available in packaged software, a reluctance to depend on an external provider for a business critical infrastructure element, and a perception that development and maintenance costs can be minimised by coding in-house.

Conversely, in addressing the first concern there is a real risk of concentrating on special functions to the detriment of pursuing best practice in wider processing, and also of cementing in legacy business practices with a resultant loss of flexibility.

And while anxiety about the commercial risk associated with dependence on third parties is understandable, in reality the risk of losing or re-allocating in-house skills is usually higher. In the case of out-sourcing, it is worth questioning whether a local IT consultancy with a handful of end users (probably all using different applications) really provides more security than a vendor of the same or greater size supporting a larger, distributed user base, all on the same software platform.

In-house or out-sourced bespoke ERP software can indeed be less costly to develop than packaged solutions, because the total function count can be restricted. However, the development costs are borne exclusively by the single end user, whereas in the case of packaged software the costs are distributed across many end users. Maintenance costs can also appear lower for bespoke applications, particularly if (as is often the case) on-going development is reactive and minimal, and also because real costs are often partially absorbed into general overheads. Software maintenance and on-going development for packaged products benefits from the input of a larger number of users, and is hence likely to progress at a faster rate and provide better value.

Software Development - More Isn't Always Better


Early Enterprise Resource Planning (ERP) systems often started life as in-house development projects for large manufacturing organisations. Other products were developed for specific industries, and only later broadened to capture a wider market. Most of these pioneering systems were written for mainframe computers and then various flavours of Unix, almost exclusively with a crude 'character' interface.

The connection of PC's through local area networks (LAN's) eventually led to DOS based systems with similar interfaces and functionality. Most of this software was coded before object-oriented development tools were available, and hence do not benefit from the structured approach offered by this technology. This makes for cumbersome code that can be unreliable, and costly to develop and maintain. However, vendors cannot just discard this huge investment in legacy software.

To extend product lifecycles, Windows-based front-ends were later "bolted on" to some systems without improving the underlying code. It was the mid to late 1990's before some of these legacy products were eventually re-written or replaced to take full advantage of the latest operating system (OS) architectures and object-oriented programming techniques, but many are still on the market now.

In addition, there has been a tendency for larger businesses to demand custom functionality from which many vendors derived healthy revenues. This customisation typically ends up in the standard software leading to "bloatware" (overblown software containing an excess of little-used functionality). Such ERP software is going to demand substantial resources to operate, maintain, upgrade and develop. This can be exacerbated by high training and operational costs due to poorly designed user interfaces, and a bewildering array of superfluous functionality typified by "window clutter" and "menu sprawl".

Vendor Selection - What Should We Be Looking For?


In the case of the very largest manufacturers, it is still not unknown for in-house IT resources to design, deploy and develop business software to the exact needs of their organisation. However, most companies have come to recognise the significant advantages in sourcing business applications from established vendors, albeit with varying degrees of process-specific customisation depending on the size of the organisation, and hence the available budget for programming services.

These advantages range from generic functionality already in place, through vendor experience in similar industries, to long term stability and hence security of support. One of the key reasons given for change from in-house or locally written systems is the loss of key project members - through staff turnover or a local IT provider no longer trading.

As a result, the late 1990s saw an established and growing market place with a wide range of applications and vendors to choose from, with growth further fuelled by the looming "Millennium Bug" (Y2K) issue. However, the net result of Y2K was to bring forward the decision process for ERP projects in some cases, and in others to divert IT resources into necessary infrastructure investment. The following lack of confidence in IT investment (worsened by uncertainty arising from e-commerce hype and subsequent disillusionment) led to a significant shake-out amongst ERP vendors, with the usual round of down-sizing, acquisitions and mergers.

In order to establish the winners and losers from this process it is worth asking some searching questions of prospective vendors, such as -

  • How long has the business been trading in it's current form?
  • How many times has the business changed hands?
  • Has there been any significant new product release in your area of interest since Y2K? Is the product under scrutiny subject to ongoing development, or just part of the portfolio through acquisition?

The answers to these questions may help identify the degree of stability of the vendor, and the level of commitment to a future in manufacturing

Project Management - What Is It Going To Involve?


After the selection phase of a project for the introduction of a new manufacturing Enterprise Resource Planning (ERP) software system, the implementation phase gets into full swing. An outline plan including estimated resources and timescales should already have been discussed during negotiations, along with the expected approach to the handling of legacy data and processes.

The implementation phase typically includes the following activities, some of which run concurrently: -

  • Project planning
  • Installation
  • Legacy data and process review
  • Process modeling (sometimes called the "conference room pilot")
  • Data preparation and transfer
  • Customisation and training

All of these will converge on an agreed go-live or switchover date. Sometimes a phased implementation will take place instead of the above "big bang" approach, gradually introducing system elements to business processes as an extended project - this is appropriate where an integrated business system is not already in use, otherwise it may involve the "parallel running" of two systems, which can strain internal resources. The personnel involved in this phase will usually include an internal project head and representatives from each functional area (the core internal project team), representatives from the software vendor, along with IT support and data entry staff.

Like all Business Process Re-engineering (BPR) projects, ERP implementations can disappoint if not managed effectively. However, paying attention to well-established critical success factors can minimise the risks.

Key factors include: - the authority and mandate of the project leader to ensure activities are completed and milestones met; adequate preparation, for example legacy process flow documentation; re-assurance and training of key team members to reduce the fear of change and avoid resistance; thorough testing before committing to final data structures and processes; adequate time allocation for user training and practice.

All of these need to be backed up by effective project review and planning, clear communications, and the avoidance of over-complication wherever possible (often called KISS - Keep It Simple Stupid!).

Support resources

Call Applegate +44 (0)345 600 7177