Partilhar via

Adopting Enterprise Software

  • Artigo

A commonly asked question by customers is "How do I get my end-users to use the technology?!" This question is applicable to any enterprise software - .NET, J2EE, Client, Server, et cetera. In fact it transcends technology - it could be a process. Technology, or anything for that matter, is as good as people use it. You can have the best content management system, but if people don't use it, it's useless.

I strongly feel there are 3 pillars that IT Pros must closely examine when they want a technology to be adopted after it's been implemented. Most people focus on Migration. Others focus on education. There are three pillars: Migration, Education and Policy.

Migration - the key here is to migrate what's important from your old system or "old way of doing things" to the new. In an ECM solution, for example, you don't want to migrate all the content.

Education - education is key. You have to not only educate people on the mechanics, but you have to educate them on how this will eventually improve their productivity. both are critical... how you educate users depends on the company dynamics, number of people, complexity of the system, et cetera. Depending on the role, you want to consider having breadth and depth training programs. breadth, for example, is web-based training... depth is more traditional instructor-led training.

Policy - this is often overlooked... the success to an effective deployment is having this element. As long as the old system remains, the majority of people will continue using the old system... it's easier, it's more familiar... and hey, "if it's not broken, why should they change." One *extreme* example of policy is "from now on, the old system is CLOSED. you MUST use the new system." This policy can work in some scenarios... but it can cause frustration, confusion and dissatisfaction. A more reasonable approach is, "after 6 months, we will turn this off... click here to use the new system." I have over-simplified it, but essentially, you want to give people notice and an opportunity to learn the new system.

Needless to say, depending on the complexity of the system, business drivers and mix of the above 3, you might have situations where you have co-existence of the old system and new system for a certain amount of time... maybe the older content lives in the old system for example. You need to very carefully architect and think about how this will affect the longer term adoption of the new system.

A simple example - let's say you want to deploy a new Portal. but, everyone is used to the old portal and the old way of doing things... even if it's less "productive". You may want to have the new Portal, initially, live side by side and offer new services like enterprise search... so the new portal becomes the landing page and the old portal continues serving some of the content. In time, you can start migratiing some of the content based on usage... some of this migration, btw, can be at the individual level... that is to say, part of your policy can be that individuals must move their content or mark their content for migration by a certain date. And with a combination of education and policy, you can slowly de-emphasis the old portal. Again, the approach is very specific to the business and the set of users.

Net/net: think about your users. Think about your business... and then make sure you consider these three pillars... b/c at the end of the day, your solution is only great if people use it.

Comments