Template Based Deployment


From discussions with customers and colleagues I have found that deployment approach is a subject of increasing interest. As Dynamics AX has increasingly moved toward the enterprise end of the market, the need for a more regulated deployment approach has become apparent.

In one of my previous posts on deployment I discussed the merits of a loosely coupled approach to deployment of Dynamics AX. In that post I also briefly touched on a template based approach and I would like to explore that subject more in this text.

The Core Solution is Dead
In years past we used the term “Core Solution” to describe a solution, which was designed centrally and deployed locally essentially without alteration. For a while this approach worked well because many Dynamics AX projects were centered on development of modifications. The Core Solution also worked because we were mostly deploying Dynamics AX in companies with a fairly homogeneous process landscape. Now, I believe, the Core Solution approach is dead because the world we are entering is increasingly heterogenous. Please stay with me and read on…

Long Live the Template
As we have now moved toward more configuration-based implementations, the template approach is becoming increasingly important. To be able to design a common template and roll it out to subsidiaries is obviously a more efficient approach than doing individual implementations. However, in my experience the template approach will not work if the business is not fairly homogeneous. In heterogeneous business environments it can be very hard, if not impossible, to actually agree on a template. This results in endless design workshops and spiraling costs. To defer the problem (and costs) some companies decide on a pilot / cumulative template approach: start with a fairly representative business unit and use them for a pilot implementation, use the pilot as the template foundation and grow the template as you move along to other business units. In my view, this approach is also problematic because it may result in some very bad architectural decision at the beginning of the project. Also, it sends the wrong message: it is OK to add stuff!

Templates in my view should always be tightly controlled to work.

Will templates actually work, then? In my experience, yes, but only if the business if fairly homogeneous in terms of processes. Otherwise you will spend too much time trying to cater for local variations and in fact you may end up constraining the business you were try to help in bathe first place.

A World of Workloads
In future I believe that we will move away from a monolithic software approach. We will increasingly support individual workloads such as HR management, SCM etc. Some deployments will contain multiple workloads, but in a effort to achieve faster implementations with less risks, customers are likely to keep scope limited.

With workloads and loosely coupled systems coming to the fore, I believe it is time to focus more on the glue that tie the enterprise applications together.

First of all, it is pivotal to have a master data management strategy. Without this it is virtually impossible to make processes work across the enterprise. Also, with aligned master data and classification you are able to leverage performance management across the enterprise.

Secondly, we need to be able to support cross-enterprise transactions and processes. With our master data aligned and harmonised it obviously becomes less of a problem to achieve this. With the service layer of Dynamics AX (see my previous post) up to scratch, we are now more easily able to bind different deployments together to form a coherent process landscape without resorting to a monolithic deployment approach.

Personally, I believe this approach to be better unless very special circumstances allow a template to be designed and built that will cater for the whole enterprise without the need for local variations. I believe this work load approach to be more agile and ultimately less expensive because enterprise-level companies are rarely able to implement a monolithic system within a reasonable timeframe.

Is there still a case for templates. Yes, absolutely, I think. If the circumstances are right and also if the scope is limited; go for it! Templates make a lot of sense when in comes to data classification and policies. Just make sure to apply them where there is a reasonable chance of success…

To ATP or not to ATP? That is the Question…

Forecast 1

Without pretending that my Shakespeare recital abilities go far beyond the above paraphrase, I am using the title of this post to ask a fundamental question about how we go about implementing a central feature in Dynamics AX namely Available-to-Promise (ATP).

For a number of reasons many companies would like to avoid using reservations during sales order processing in Dynamics AX. Firstly, reservations introduce the problem of forward orders where we reserve stock for future customer orders, which we could use to fulfil customer orders tomorrow instead. This obviously increases working capital and reduces customer service levels. Also, until recently (with the introduction of Pallet Relocation in Dynamics AX 2012 R2), making a reservation during sales order processing would have tied that pallet to the current location until it was shipped.

With these drawbacks relating to reservations in mind, many companies consider using the Available-to-Promise (ATP) feature in the sales order module. Microsoft’s slightly cryptic definition of the ATP calculation looks at available stock from previous periods, future inbound stock and future outbound stock. If stock is available within the ATP time fence, the earliest fulfilment date can be given to the customer. If not, the product’s lead time is used instead (whatever happens, if the product hasn’t got a lead time is anybody’s guess…).


  • Master data (lead times) are not accurate.
  • Supplier performance is poor.
  • The procurement department is not updating confirmed receipt dates from suppliers.
  • Available stock is prioritized based on customer ratings.

I believe most companies will accept that their master data is not always entirely correct. Now, this may not be a major issue because the product lead time is last resort in the calculation. However, I believe that many companies working with overseas suppliers have a supplier performance significantly lower than 100%. Lastly, if a company experiences shortages on a regular basis, they will need to prioritize stock to preferred customer. In that case, the ATP calculation will not have been of any use. All of these issues in combination can make ATP as unreliable as just giving a fixed lead time. Most companies in that situation would probably be better off focusing on improving their supply chain performance.

In essence, my conclusion is this: if you have a high degree of data quality, process discipline and high performance suppliers, ATP is probably for you. If not, think twice before heading down that route without solving the root cause issues first.

Best of luck with getting to grips with customer promises…

Set Your Services Free


With Dynamics AX 2012, at last we have a genuine platform for making Dynamics AX a fully functioning component in a service oriented architecture. This article is only focused on the services capabilities of Dynamics AX. If you would like to read more about designing and deploying a service bus, this book by David A. Chappell is quite good.

Some people may ask, why we should bother with services in the first place? 

When we deploy Dynamics AX we almost always have a need to integrate with other systems including legacy systems. Obviously we can deploy the usual array of integration patterns including database triggers, flat files, message queuing etc, but I believe services have a number of advantages that I have tried to describe in the following:

Interoperability; First of all, a services based architecture solves the age-old problem of interoperability. If designed correctly, service operations allow systems to speak together within worrying about character set, binary compatibility etc.

Incapsulation; a service should adhere to the principle of hiding the actual implementation  behind the operation signature. This means that the service consumer does not need to know anything about how the service is implemented. Obviously, this is a great advantage for a developer unfamiliar with X++ calling a service in Dynamics AX.

Loosely coupled; with services, you are able to couple systems loosely, so there are no hard bindings on a transactional level. As long as the service adheres to the principles of incapsulation, the system consuming the service can trust the transaction integrity of the service provider. A multi-instance deployment of Dynamics AX (see my previous post), is the ideal example of loosely coupled systems, where a service layer provides the glue that integrates the two systems together without hard bindings on any level.

Legacy support; if you are trying to integrate Dynamics AX with legacy systems, using services is often a good and cost effective way (if the legacy systems can actually be wrapped in services). This effectively solves the problem with interoperability (see above) and allows the developer to ignore implementation details on the legacy platform.

If you want to read more about service oriented architecture Wikipedia has a reasonably enlightened description.

Document Services

The cornerstone in the Dynamics AX services implementation is the Document Service. A document service consolidates all the tables necessary to Create, Read, Update or Delete (CRUD) a document entity such as a purchase order. As you well know, an actual purchase order in Dynamics AX consists of PurchTable, PurchLine and a host of other support tables. The document service makes sure that all the relating tables are updated or read correctly. The document service is based on a Dynamics AX query that tells the service, which tables and fields that  are included in the service interface. A wizard makes sure that all the necessary artifacts such as the WSDLX-schema (XSD) and WCF configuration file are generated.

Once your document service has been deployed, other systems can use it to interact with Dynamics AX allowing for a high number of business scenarios to be supported.

Custom Services

If you need to expose complex business functionality, which is not directly linked to a specific business document (see Document Services), you are able to write custom services and expose them to systems outside Dynamics AX. In essence, this allows you to support pretty much any service integration scenario, but it does require more X++ coding than Document Services.

System Services

If you only need to query data in Dynamics AX, Microsoft has now created a system service, which allows you to build a query, submit it to the service and get an ADO.NET dataset in return.

Dynamics AX 2012 also two other systems services namely

Meta data query; this service allows an external program to query meta data in the AOT.

User session query; a program can query the user session context.


One of the best features of the services implementation in Dynamics AX is its ability to use both XSLT and managed code to perform transformation. This gives the developer a wide range of possibilities when it comes to choosing the right technology, but it also allows non-X++ developers to take part in the development work. You are also able to perform straightforward value substitution and value mapping as part of the messaging framework.

Protocols and Bindings

With Dynamics AX 2012, Microsoft has pensioned of the semi-proprietary adapters for BizTalk and MSMQ. Instead, the Application Integration Framework (AIF) is now driven by Windows Communication Foundation (WCF). By default WCF is hosted in the AOS service, but can also be deployed on IIS (for internet deployment scenarios).

With WCF the AIF supports both synchronous and asynchronous communication via the netTCP, http and MSMQ protocols.

The Case for Delta-Loading via Services

If you need to delta-load other systems with only the changed records in a table (document service), you are able to do this using the changedKeys operation on the Document Service. A couple valid scenarios for this feature are:

  • Shopfloor screens showing operation workload data
  • Master data management

To leverage this feature you need to enable SQL Server Change Tracking on the relevant tables. You can read more about Change Tracking here.

A Deep Dive into the Application Integration Framework

If the above text made you think that taking a service oriented approach to architecture and development is great (as I do), I can strongly recommend you read this book for a deeper dive into the implementation details of AIF.

If you would like to read more about the standard protocols and technologies underpinning the AIF, I propose you visit the W3C web site.

The Purist’s View

I am certainly not blind to the fact that there are other solutions out there, which will allow other systems to integrate with Dynamics AX without any development effort. However, being a bit of a purist I believe that Microsoft has set a strategic direction with AIF and services and we should all take notice and start building services – especially if we believe that the future belong to cloud services and loosely coupled systems…

Good luck with creating your own services layer!

Pallet Relocation

Pallet 1

This post on the Microsoft SCM development team blog caught my attention. For years we have struggled with the problem of not being able to move a pallet once reservations were made against it. This new pallet relocation feature now supports the common scenario of pallets transfers between locations allowing for far more efficient warehouse management operations in Dynamics AX. The feature is availble in R2.

Best-of-Breed vs. The Integrated Suite… What’s Best?

Horses 1

Following on from my last post where I discussed the pros and cons of multi-instance deployment I felt that the next natural subject would be to discuss whether an integrated suite or a best-of-breed strategy is more appropriate when it comes to deploying Dynamics AX. When I write best-of-breed, what I really mean is using a solution outside Dynamics AX to add to the function of the system – I am just assuming that you select the best-of-breed solution for that purpose.

Before going into the merits of each approach, I would like to take a step back and remind ourselves about the history of ERP. If I remember correctly, ERP grew out of financial and manufacturing packaged software in the mid-nineties. The term ERP was, as you probably know, coined by Gartner in the early nineties and used to describe packaged software, which combined multiple functional areas in an integrated software suite. Every software vendor jumped on the bandwagon and started building out their functional footprint to be able to claim feature superiority and win sales. This led to a feature-war that lasted for at least at decade (maybe it is still on) turning the software packages into monlithic monsters.

As I discussed in my post on deployment topology, this discussion probably isn’t very relevant in smaller implementation projects where the functional footprint of Dynamics AX is sufficient and the benefits of integrated master data and transactions are significant.

The Role of the ERP Suite

Before I start discussing when best-of-breed is applicable let’s take a look at the role of the ERP suite. Most ERP suites, including Dynamics AX, are designed with one or more core industries in mind. In Dynamics AX’s case, these core industries are distribution, retail, manufacturing, public sector and services (you can read more about these industries on the Dynamics AX site). Within manufacturing, Dynamics AX supports both discrete and process manufacturing modes.

Within these core industries, Dynamics AX will provide integrated functionality to support the main industry scenarios, but as you get further away from the core, the functionality becomes less deep and the case for a best-of-breed solution becomes stronger. The question is: when is the time to go for a solution that is not part of Dynamics AX?

The WMS Example; An example of this is the WMS Dynamics AX module. The module has the key features to support goods receipt, put-away, transfers, counting, picking, staging and despatch. For many Dynamics AX users, the functionality will be sufficient (especially if augmented with a module for handheld devices like rfsmart). However, if your core business is high-volume logistics and warehouse management with requirements for voice-picking, transport planning and management, labour management, cross-docking and container handling, maybe you need to look elsewhere. I believe this to be especially true, if the company has one or more centralised distrubtions centres (DC) that sit in separate companies. In that case, in Dynamics AX you are essentially required to supply the sales companies through an intercompany model creating hard-binding transactions. By deploying a separate WMS solution such as Manhattan or Red Prairie, you will avoid the hard-binding transactions in Dynamics AX. In many case there will also not be a need to a real need to use intercompany, and last but not least, you can avoid the physical storage dimensions allowing for reservations on warehouse level or even simple ATP fulfilment. For me, the advantages of this approach are clear to see:

  • The Dynamics AX implementation becomes simpler.
  • No hard-bindings on a transactional level.
  • Access to the full compliment of WMS features.

However, one needs to be aware of the challenges of this model:

  • Keeping the systems in sync.
  • Making late changes to an order may be cumbersome.
  • The return order process must be very clear to avoid confusion.

The following picture shows an example of how Dynamics AX can be integrated with an external WMS system on a conceptual level:


This example shows a simple approach to integrating the two systems with a one-directional integration policy. In my experience, it is pivotal to stick to this one-directional approach to ensure clear processes and minimize the requirement for reconciliation. This goes for many other integration scenarios than WMS.

What would the business gain from taking this best-of-breed approach on WMS? In my experience there are the following business benefits:

  • The DCs can operate independently of the ERP system allowing for local process optimization.
  • External WMS packages have a broader functional footprint giving the business an opportunity to improve operations by implementing best-practice processes.
  • Lower TCO since neither Dynamics AX nor the WMS package will require the same level of bespoke development because of the significantly higher functional level.

So in short my conclusion is this: if you have significant business areas that fall outside the core processes of Dynamics AX, you are probably better off deploying a best-of-breed solution rather than developing bespoke modifications to support the current business model. With this approach, I believe you reach a lower TCO and you allow the business to adopt best-practices across all important business areas. One has to bear in mind, that by focusing on using the standard solution this way, the best-pratice usage of Dynamics AX core processes is also likely to improve.

Workloads Where Best-of-Breed is Applicable

Based on my personal experience here are some other workloads that could be candidates for best-of-breed solutions:

Output Management; if your company is multi-country, multi-channel, multi-brand etc. using SSRS to format your precision layouts such as invoices, packing slips can be quite cumbersome. Ouput management packages are written for this specific purpose and also allow multiple destinations.

Demand Planning and Forecasting; let’s be straight: Dynamics AX doesn’t have any, so if your S&OP strategy execution requires this type of functionality look for other solutions in the marketplace. Many of these already integrate with Dynamics AX, so it is a great way to augment the system.

Payroll; even though Dynamics AX 2012 R2 now has a payroll module for the US, in other geographies we are not so fortunate. So if you are in Europe or Asia and need a payroll system, look elsewhere.

Financial Budgeting and Consolidation; Albeit Dynamics AX has improved significantly with 2012 when it comes to financial management we are still some way short of what some of the purpose-built packages do when it comes to controlling and consolidation in the enterprise. Perhaps in a release cycle or two we’ll get there, but in the meantime it is worth considering if your requirements are met with Dynamics AX.

The Consequences of a Best-of-Breed Strategy

Obviously, for a lot of businesses the best-of-breed strategy may only make limited sense and very often you have to make a judgement on a case-by-case basis rather than adhering to a general strategy. But in my experience, a business is better off by considering the best-of-breed strategy when the gap between business requirements and the standard functionality becomes so wide, it requires significant bespoke development. In that case, you should make a feasibility study to ascertain the TCO of all options and choose the option that generates the lowest TCO with the highest business benefits.

What I have written is based on my personal experience, but I would strongly welcome comments that argue the opposite view because I think this is a very important discussion to have when you enter into a new project.



Dear Reader of my blog:

My heartfelt thanks for reading my thoughts and your kind feedback.

Almost 200 people have read my posts since Saturday, so to me that proves that you share my enthusiasm for Dynamics AX! Certainly makes it worth spending a Sunday afternoon writing about deployment topology 🙂

I would like to encourage you to post comments on my blog… I believe cross-pollenation of critique and ideas will benefit our community and move us closer to our common goal of making the best use of Dynamics AX and its ecosystem.

Again, thank you following my blog.

NB: Expect my next post to be online by the end of this week…

The Single-instance vs. Multi-instance Debacle


Over the years, I have been involved in a lot of discussions with colleagues and clients about the deployment topology of Dynamics AX. Should we deploy as single-instance or multi-instance? For many people the answer was a no-brainer: single-instance, because logically it should provide the lowest TCO, if we only have one system.

However, in my experience, this argument often isn’t true as I would try to explain further down in this blog post. At this stage it is worth pointing out that until version 2012 R2 we have not been able to deploy single-instance if the solution was used across multiple regions, because some regions such as China and Russia could not be combined in the same instance (for technical reasons). Since this is no longer the case, I will, for argument’s sake, assume that we are now free to deploy as we see fit.

For the purpose of this blog post, multi-instance is defined as more than one instance of the Dynamics AX application deployed within the same corporation whether it be hosted on locally or centrally placed hardware.

Before I start discussing the arguments, I would ask the question: Why would you deploy Dynamics AX as a multi-instance solution in the first place?

In my experience smaller businesses with few business units and limited geographical reach should never consider deploying Dynamics AX as multi-instance, but for larger corporations with diverse business units and a significant geographical footprint, it might be the best way to go for a number of reasons, but the main one in my experience is:

When Single-Instance Works

In a single-instance deployment the requirement for aligned business processes and master data structures is significant and not many businesses have achieved this level of alignment before commencing the ERP implementation. Therefore the ERP project becomes the change agent for business harmonization and most times, timelines and budgets do not allow for this causing the projects to fail or at least not meet their objectives.

Let’s be clear about this: in a lot of scenarios, single-instance is the best option!

  • If your business is not diverse and
  • If you have harmonized your business processes and
  • If you have a fairly harmonized and normalized set up master data

then single-instance deployment is for you. Especially if you are deploying to a limited number of business units (5-10), you should be able to create the necessary harmonization to allow single-instance deployment.

Also, if your manufacturing mode is Make-to-Order or Configure-to-Order, the advantage of using an integrated system with intercompany relationships is likely to win the argument for single-instance deployment because you automatically receive the manufacturing data such as BOM, routing and configuration.

Clearly, if you are not able to answer yes to the three questions above, you need to consider the pros and cons in relation to your deployment topology. If you processes are not harmonized before your start the ERP implementation project, they are very unlikely to become so by deploying the same system to all business units. You are more likely to create disruption by forcing business units to align to business processes they are not ready to adopt and could prove inefficient for their business set up.

If you seek to implement the same processes across manufacturing, distribution and retail business units you are likely to create inefficient and even broken processes because a single system will struggle with this diversity range without creating exceedingly cumbersome processes.

The “Writing Mods Once” Argument

Most people would argue that writing a modification once and deploying it to all business units is more efficient and on the face of it, this argument is true. However, if you are a large business where all stakeholders need to have a say in the design and every subsequent change must be governed and retested across the whole business maybe the TCO isn’t quite as attractive. As part of your topology assessment, consider the time you expect to manage modifications across a five period before deciding.

The “Template Deployment Only Works with Single-Instance” Argument

Many businesses implementing Dynamcs AX would like to design and build a template with subsequent deployment across the business. This is, for obvious reasons, a lot simpler if all the business units use the same instance of Dynamics AX and therefore the same processes. However, consider this common business structure scenario: the business has three distinct divisions namely manufacturing, distribution and retail. In that case the concept of a common template across these diverse businesses does not necessarily make sense. I will not discuss template based deployment in this blog post, but just point out that there is a relationship between deployment topology and rollout strategy.

The “Upgrades Will be Less Expensive” Argument

Potentially this is true, but in my experience it never seems to be the case in reality. Upgrading modifications that have been written to serve multiple purposes never seems straightforward nor does it appear easy to upgrade a system that contains the full corporate transactional database. With a multi-instance approach you can stagger the upgrade process allowing a more generous data migration window.

OK, so now I have made a lot of arguments in favour of multi-instance deployment and it is time to put my preferred approach across… I am actually going to put my money where my mouth is.

What Would a Multi-Instance Deployment Topology Ideally Look Like?

In the following picture, I have tried to outline what I have found to be an ideal topology for businesses looking to deploy multi-instance Dynamics AX. The example is based on an example business with individual manufacturing, distribution and sales / retail business units – likely to be distributed across the globe. Obviously, this is only one example, so the point is that the business and geographical spread is significant.


At the core of this topology is a master data management system. Dynamics AX is likely to be the system-of-record in most deployments, but I would strongly recommend deploying a purpose-built Master Data Management (MDM) solution. The above conceptual example does not show all the other systems Dynamics AX must work with when it comes to master data, but things like eCommerce, other ERP systems and PDM / PLM spring to mind. With a proper MDM system, this integration becomes easier and of a higher standard.

As the example shows, Dynamics AX has been split into three (blue boxes) separate instances. To allow coordinate between the three instances, we need three things:

  • A system that collects demand and through S&OP strategies propagates the demand to the distribution and manufacturing instances.
  • A data warehouse that consolidates information from all three instances into a single harmonized view.
  • An integration platform that allows transactional data to flow between the instances.

To be able to feed the manufacturing business unit with the correct orders and forecasts, a  demand and supply chain planning such as Logility or Demand Solutions is required to collect demand and calculate requirements based on inventory, constraints, service levels etc. Obviously, this approach mainly works in a scenario where the manufacturing mode of the business unit is make-to-forecast (MTF) or make-to-stock (MTS) instead of MTO or CTO. In a MTO / CTO scenario this approach is also applicable, but a single-instance approach may be more appropriate. I believe that this approach will also work in an assemble-to-order (ATO) context.

For obvious reasons, the multi-instance deployment strategy must be underpinned by a clear data warehouse strategy enabling business decision makers to analyze data, which has been consolidated and correlated across the entire business. With a sensible MDM strategy and appropriate tools, the mapping of analysis categories can be made in the MDM system to allow each business unit a degree of freedom in determining the categorization scheme most appropriate to their requirements.

In the multi-instance scenario, the idea is to allow a certain degree of freedom for each business unit when deploying Dynamics AX. Whether a corporate chart of accounts is appropriate or not, is often a matter of policy, but by including a financial consolidation solution such as Hyperion will ensure that financial data can be fed directly and correctly into the corporate financial platform.

At the End of the Day…

… whether you decide for single-instance or multi-instance deployment is more about the business than a technical issue. Dynamics AX 2012 R2 now supports the manufacturing, distribution, retail and services industries in a single codebase so the argument for single-instance deployment has just become slightly stronger. On the other hand, I have seen numerous examples where lack of process harmonization has made single-instance deployment virtually impossible – or at least very costly, so do not underestimate the change programme required to achieve total harmonization.

Going for multi-instance deployment requires Dynamics AX to be augmented with some best-of-breed solutions to compliment it. This introduces a discussion on best-of-breed vs. integrated suite, but that discussion is for another day and another blog post.

What I wanted to convey with this blog post is the point that before setting out on a multi-business-unit ERP implementation journey, spend time on ascertaining your organization’s readiness in terms of process harmonization and willingness to adapt to common process and procedures.

For more information on the Dynamics AX system architecture see Microsoft Technet.

For more information on planning and deploying Dynamics AX see the Dynamics AX 2012 Implementation Planning Guide.

In coming blog posts, I will discuss some of the issues relating to multi-instance solution architecture including:

  • Output management – Mastering the multi-language, multi-channel, multi-brand challenge
  • Best-of-breed vs. the integrated suite… What’s best?
  • Financial controlling
  • Integration architecture
  • ERP as the driver for change
  • A process vs. information implementation approach
  • Template based rollout – are they any good?
  • Master data management – The day of the Data Steward has come…

Why is ERP so unsexy?

Hello and welcome to my first post on this blog. In this blog I will be sharing my views on a number of issues relating to the world of ERP in general and Dynamics AX in particular. The topics will range from general issues to more specific and technical issues. The topics I write about will be selected by myself and be entirely subjective to what interests me at the time.

DISCLAIMER: Please note that the views in this blog are my personal views, and do not represent the views of current employer.

Anyway, to business; recently I commented on a question in a LinkedIn group about the skills shortage in the Dynamics AX VAR channel. Now, I have heard this point-of-view ever since I started out with the product in 1998 and noone seems to do anything about it – much like the weather, actually.

My conclusion was that the skills and talent are out there, but we are not always able to attract them and train them in the right way. One of the reasons for this, I believe, is that ERP is generally considered to be unsexy. Why is that? We are working with the core processes of the businesses we work for. We are often able to improve our clients’ business. We work directly with decision makers. What’s unsexy about that?

Obviously, I do not have the silver bullet answer to this, but I think it is time for us as a community to consider how we improve our image. Maybe we should start by making sure that our client engagements are successful and thereby start a virtuous circle of good projects and therefore good publicity. I also believe we should engage more directly with universities to inform students on the exciting careers path they can find in ERP, but most importantly we need graduate on-boarding programmes that allows students to come on board and build their careers in a structured way…

I welcome views on this topic, because I feel that we need to think out-of-the-box to ensure that the next generation is there push us 40-somethings for the next 20 years.

Let’s make ERP sexy again (remember the ’90’s….?).