jump to navigation

ERP – The User Conference 08/27/2012

Posted by TBoehm30 in ERP.
Tags: , , ,
1 comment so far

This month I went to the User Conference for the ERP system that I have been implementing.   It is incredibly important to network with other users of the same software.  I met numerous people who have struggled with the same issues I have, and had great conversations about their insights.  I learned about other ways the software can be used, and workarounds for known problems.  I traded contact information with people who might be able to help us in the future, or whom I might be able to one day give a hand.

The conference was huuuge; there were around 4,500 people.  Apparently we trended on Twitter twice during the week.  They included partners who sell and support the software, they had customers, and they had vendors who make bolt-on products.  There was a trade show with booths for companies that work with the software.

I loved walking around the trade show area, where I could learn so much about the possibilities for the IT department.  I viewed demos of scanning equipment which could improve the manufacturing process and integrate seamlessly.  I had a discussion with the people at a company who have a better alert system that reads data right from SQL.  I saw several great BI products to make dashboards or reports.

They had presentations running all day covering all kinds of subjects.  Obviously, the software was a main topic, but they also had generic business presentations to talk about creating a vision, or managing technical people.  I went to all the presentations that I could possibly get to, but there were more than any team of people could cover.

The presentations were great for talking about using the software in new and unique ways.  I had an interesting discussion with an IT director on why he bought some software to automate sending out invoices.  The ERP system could be made to do it, but it would have taken the IT department quite a bit of time and opportunity costs to get it done.  The automation company came in with consultants, talked with his sales staff, trained them on the software and got everything setup. He and his team then got some quick training later to be able to support it.  While all of that was going on, he could concentrate on other more important projects.  It was a win-win for them.  I kept thinking about how I could get the ERP system to do the same thing, but realized how much time it would take to support.

I did a presentation on security that was well received.  I talked about how I helped a company create a very complex security system within the ERP system without customization.  I showed a group of around 80 people what was possible when using the software to its fullest potential.  Hopefully some of them got some good ideas from the hour-long talk and will be able to implement them easily.  One person even surprised me and asked about setting up even more complicated security.

After the official activities were concluded each day, there were cocktail ‘parties’ hosted by companies who wanted our attention.  These were not only fun, but included people that I would not have otherwise gotten a chance to talk to.  These were some of the movers and shakers at their own companies.  They were the IT people who really understood the software and could easily discuss issues and problems.

I saw plenty of people skipping out on a presentation or activity to use the Wi-Fi to dial in to work and fix a problem or two.  I thought about how sad it was that their company couldn’t let them alone for just a few days to participate in this amazing experience.  Instead of learning about new possibilities, they were stuck dealing with the status quo.  But at least they were there and got a taste of the future. 

I have worked with people who couldn’t justify the cost for an out-of-town trip and three to five days out of the office for this kind of event.  I say to them that the cost is higher when no one goes.  An ERP system from a large software company has so many people with good ideas that they shouldn’t hide from them.  They can’t operate in a vacuum and ignore the possibilities that exist.  They have to learn that it’s a global world out there and technology makes it happen.

Advertisements

How close is your software vendor? 10/12/2011

Posted by TBoehm30 in Software.
Tags: , , , , , ,
1 comment so far

 

The other day I had a software problem.  My client had come to me with an issue and I had to come up with a solution.  I have been working with them for a while so I know their software pretty well.  I can usually figure out their problems and either solve them or come up with a workaround.  At the very least I can use their testing environment to document all the steps to recreate the problem as well as the steps taken to try to solve it.

My client has a valid contract with the software vendor and has full access to their help desk.  I am sure you have dealt with many ‘help’ desks and are completely familiar with what that means.  Some of them are very good and some of them are worse than a hot day in the desert.  I have to admit that this one is actually pretty good.

The trick is in the communication.  The people who I work with can’t always communicate their problems in such a way that the help desk can solve them.  They also have trouble understanding the responses.  Sometimes the tech-speak is just too complicated.  That’s where I come in.  I can help translate for both sides to get the problem solved.

Today, I found what I thought was a bug in the software.  The company that created this software is very sensitive about criticism of their programs.  I didn’t want to go to the help desk with this one until I had verified functionality with one of their senior consultants.  Since I am on good terms with several of them, my options were open.

The project manager for our implementation likes for me to go through him before talking to the consultants.  I shot him an email with my problem.  Within a few hours he had confirmed my problem, sent it off to tech support, and came back with a solution.  It wasn’t really a bug, but a setup problem.

I have dealt with many software companies throughout my career.  I have talked to people who were really good at their job, but the company was terrible; and I have talked to people who couldn’t help a cat out of a bag, even when their company was great.  A response within a few hours with a solution, going around the help desk, is above average support.  I would recommend that any day of the week.

When you are looking for software it is important to determine what kind of relationships they develop with their clients.  Sure, you will get references and talk to them about the pros and cons about the software; but you also need to find out about their responsiveness.  You need to find out about their personnel.  Do they stay in touch with their clients?  Do they come back to find out if there are any lingering issues?

Before you make a decision on your software, find out who your main contact will be.  Try to meet with him or her at a time and place where you have plenty of time for questions.  This person needs to be someone with whom you can trust and build a relationship.  They need to listen; you need to feel like they are listening to you and not thinking about what they will say next.  They need to be flexible.  Throw them a hypothetical curve ball; how do they react?

If this person doesn’t meet your criteria, don’t abandon the software vendor entirely, just ask for someone else.  Most companies would be happy to switch personnel if it means a chance for a sale.  Make sure you still have time to repeat the process with someone new.

My criteria is for someone who understands that it’s a global world out there and Technology makes it happen.

Keeping the Meeting Going 05/07/2010

Posted by TBoehm30 in Project Management.
Tags: , , ,
3 comments

My client recently asked if we needed to keep up the weekly PMO meeting. This is a company that has 4 Business Units in different states of the U.S. I explained that the only way to know what is going on across the company, and to ask relevant questions of other leaders is to have a regular meeting.

It is a very normal feeling to be annoyed with regular communication meetings, especially when there are no important projects to discuss. Most people complain about the silly meetings they have to go to, the ridiculous discussions, and the cost to the company of having all those people there. Of course they are busy and could be more productive on their own, in their office or cubicle.

Good Meetings
Sometimes, however, meetings are important. Meetings that have a competent person running them, have a set agenda, and don’t run over can be very productive.

  • At the start of a project, meetings are essential for brainstorming, gathering requirements, forming the team, and setting a schedule.
  • Milestone meetings can be very beneficial to coordinate important steps in a project. The meeting could also be helpful in letting everyone know the status of a project.
  • Meetings may increase right before and during the Go-Live of a project. This keeps everyone on task, and lets them know the importance of their individual work.
  • Many managers like their group to have regularly scheduled meetings. These keep everyone informed of what is going on, and can bond people together forming a team.

In the case of my client, the meetings are absolutely necessary to keep the lines of communication open and to know what is going on at diverse locations. Sometimes we needed to make decisions for one Unit that would affect everyone. Sometimes one Unit would bring up an issue that another Unit realized should be happening to them too. Problems are discussed that can be solved by people in a different Business Unit.

The most important item in the list above is communication. Everyone at the company doesn’t need to know every little detail about what is going on everywhere. It is nice, though, when most people have a broad idea of what is happening. It keeps them involved, makes them feel like part of the team, and improves overall productivity.

Bad Meetings
The reason that most people get annoyed with meetings is that they feel nothing gets accomplished. One of the biggest reasons people stay happy at their jobs is the feeling of accomplishment. There’s nothing so frustrating as having important work waiting at your desk while you are wasting time in a fruitless meeting.

I have been to meetings where everyone says the exact same thing that they said last week. While doing support, we had weekly team meetings. Many times, when nothing big was going on, we could have just replayed the previous week’s meeting.

Once, I had to monitor a few meetings with an off-site development group. The manager of that group would point to the people in his group and say things like “last week you were 85% done, now what are you?” They would come back with silly statements like “well, I’m now about 90% done, but the 10% that is left will take me a few weeks longer than expected.” I would sit there thinking ‘Really! Does it matter how many small percentage numbers they completed this week?’ I wanted to talk about issues, about what was blocking the project, about how to get it done.

I’ve also done the meeting where I am just filling in people who don’t know what is going on, and probably never really needed to know either. They were told to get involved, and so it was my job to fill them in. I knew it was a waste of time, they knew it was a waste of time, but just in case that one small bit of important information would come to the surface, we had to have the meeting.

I’ve been to meetings where I was invited, just in case someone asked a question about my segment of the project. The meeting didn’t involve me, didn’t need me, and shouldn’t have required me. No one actually asked about my involvement and I got paid to waste my time.

Everyone has been to that meeting that was hijacked by someone else’s agenda. Nothing important got done because some blow-hard had to keep taking about his own project. Someone wanted to show us how smart she was, and just couldn’t stop talking long enough to let anyone else have their say.

How to Decide
To all of you that are about to call a meeting, I ask you to think about it first. Will this meeting fulfill a specific purpose? Does anyone have anything important to say? Has anything changed since the last meeting?

Create an agenda. Start and end the meeting on time. Don’t let people divert the topic of conversation too far from the agenda.

I told my client that communication is very important. The Business Units in different states need to talk every so often so that problems can be worked on together, and decisions are made that are for the good of the whole company. They won’t need a weekly meeting once I’m gone, but they should have it every so often. I am sure that they can find someone almost as good as me to lead the meetings.

They just need to find someone who knows that it’s a global world out there and Technology makes it happen.

How IT Can Communicate with the Business 09/25/2009

Posted by TBoehm30 in Success.
Tags: , , , , , , , ,
1 comment so far

I always find it fascinating when people don’t understand tech-speak. Like any specialization, they have their own Three Letter Acronyms (TLAs), terms, and new names for their products. It is impossible to keep up with all of them, even if you are in IT yourself.

The key to communication is explaining those TLAs to business people, or asking for clarification from IT. If either side is deficient in these tasks, then poor understanding will result. This happens all the time and there are many reasons for this problem. Understanding the causes may help both sides to become better communicators.

On the IT side, people probably have had little training or experience in good communication. Their education and beginning job responsibilities have been to solve problems. If you are good at solving the problems, then you have met or exceeded your expectations, and nothing further is needed. At my first job, supporting the West Coast with their software, we had a person who’s full time job was to be the communicator between my solutions and their problems. [Thanks Betsy] She always knew what was going on at the company, talked to the higher ups, and let the rest of us in on the secrets.

On the Business side, communication is probably the number 1 priority for their first jobs. Consultants prove their value with status reports and deliverables; project managers have meetings to keep up with what is going on, and team-leads or first-time managers report to their managers on the status of their people. They have learned the art of communication from the bottom up. However, they still may not be able to effectively communicate with many in IT.

The problem could simply be one of attention. IT people tend to be detail oriented. When they get task focused, they see the details and need to handle them. When asked for status, they will talk about what they are working on, which could be the details. Looking at the details of any project can be confusing if you don’t have the intimate details. It’s probably not what a project manager really wants anyway. They most likely want a quick summary of all the tasks, not just the current trouble.

Another problem could be one of personality. Many IT people are introverted. That could mean that talking to others, especially new people, is draining on them emotionally and physically. Even if an introverted person is good at getting his/her point across, it may be tiring to do so. That person probably won’t seek out the opportunity to talk to people who will need excessive explanations. An extroverted person, however, may just expect people to come to him when needed. If that doesn’t happen then tasks can be lost, and a crisis could occur.

Some IT people focus on the infrastructure. They like to talk about the servers, the network, the bandwidth, etc. Some IT people focus on the software. They like to talk about the programs, the operating system, the customizations, etc. If the person on the receiving end of this conversation is not fluent in the IT-speak of the moment, then this will not be a fun discussion. It is so important to be speaking the same language.

A problem that can occur between beginner IT staff and executives is one of priorities. Many IT staffers are reactive. They will fix things as they break, and then move on to the next problem. Executives, especially higher up executives such as the ones at the C-level, want longer term solutions. They want to talk about pro-active solutions. They want to know what the new system will cost, once they see that the old system has problems. It’s difficult for people with such differing priorities to settle down on one topic.

Finally, there’s the idea of independence. Many IT people are such good problem solvers that they want to work alone. They feel that if they are qualified to reach their goals by themselves, then why do they need interference? Some highly experienced IT people may have gotten where they are by being the hero and getting past any dilemma. They may not want to work with other people. It may even be worse if the other people don’t understand what he/she is doing.

We’ve all seen, or been involved in, bad communication issues between people of differing backgrounds. At work, it can be even worse. People working in different functional departments don’t always understand the other people at the company. We all need to work on our communication skills, take a look at the world from someone else’s viewpoint, and be patient.

I’m not trying to imply that this is the whole of reality, and that all IT people, and business types, fit into these categories. I am simply making observations of my world and trying to write something that might help. Knowing how someone else is thinking just may help you get your point across.

So go out there and communicate!

ERP Newsletter Articles 06/08/2009

Posted by TBoehm30 in ERP.
Tags: , , ,
1 comment so far

I have now published 2 newsletter articles with Imninc.com. The first one was a good summary of my current project on topics I had already put in the blog. This second one came out pretty good, so I am putting it here as well:
A View from the Trenches – Part II
In part one of A View from the Trenches, I introduced myself as a technology consultant working with a medical manufacturer that needs an ERP system (Enterprise Resource Planning). I was brought in to run the software selection project for the system, and I am the full-time driver for a large committee consisting of several representatives from several business units.

The last article ended with full buy-in from executive management as I walked through the challenges and political implications of working with a large committee. Now, we’ve reached a new phase: preparing for go-live.

Large software implementations such as ERP systems take a lot of coordination and effort to keep on track. Once the initial excitement has tapered off, people have trouble staying focused. They may feel they have plenty of time before go-live, and they aren’t too worried about project tasks, because they can make up the time later.

I’m living that reality right now. We are planning the go-live for the first of September, so that gives us all summer to be ready. We just finished four weeks of meetings to go over software settings and business processes. We had very good participation, and the results were promising. People saw the new processes, got some experience with the software and received their assignments for the next few weeks. It seems fairly cut and dry, but in most projects, managing people and behaviors is the biggest challenge of all.

I understand how my client’s employees must feel. They already have the full time job of keeping the factory going by making products and bringing in revenue, all while dealing with training, implementation and adaptation of a new system. But their business performance is important to me as well. As an outside consultant, I’m getting paid to help drive the implementation without disrupting ongoing operations. I can’t overwhelm them with project tasks, but it’s my responsibility to keep them on target with the project.

Companies bring in consultants like me to augment their staff in running large projects. This particular client runs very lean, and doesn’t have extra staff that can concentrate on special projects or drive system implementations. Motivating busy staff to stay on track with a project while balancing their daily responsibilities takes a careful balance of meetings and assignments. We meet once a week to discuss progress, but that is not enough. I try to talk to everyone in the PMO (Project Management Office) as much as possible, assigning deadlines and explaining how one person’s task relies on another person finishing their work. No one wants to be the bottleneck, so these discussions keep everyone focused on the goal.

Giving people specific tasks with a real timeline allows the project to continue at a steady pace. We avoid disrupting normal operations, and allow leeway for emergencies that tend to pop up, but the project must go on. We push forward because this new ERP system will allow the company to close the books much faster than the present system. Soon, they will have better insight into their operations, inventory and cash flow.

It’s common knowledge that the new system is a key step toward growth for the company, with numerous benefits. However, it is difficult for anyone to stay focused for numerous consecutive months. The exuberance from the beginning of the project has been drained by meetings, details and day-to-day responsibilities. We are now at a point where motivation is critical to maintain momentum.

So, what have we done to prepare for go-live? One of my first steps was to figure out individual jobs that would lead to the larger tasks on the project plan. I then described the jobs to the people who needed to pass them out to their team. We had to be ready for the first conference room pilot in a couple of weeks. Our plan was to get all the right people in the same room and simulate a manufacturing cycle with all related accounting activities.

I found that an informal description of tasks didn’t have the intended result. The information was not passed down, and people were not doing their work for the project. No one made it a priority to learn the system, get processes ready or take responsibility. There was a false perception that there was still plenty of time to get all of that done, just not today.

Around this time, I had a meeting with the right person – a staff member who could see the big picture and how it impacted the company. When I described what needed to be done, he started to get nervous. He could see how much information was needed and began to ask questions. I immediately asked him to help me get people more involved.

We gathered the troops in a large meeting where we went over the system and explained the project status. I formally asked them to send me information about their goals for the project by offering a sample list of scenarios and asking them to look at the list and follow-up by determining their area of responsibility. Creating a starting point for team members prevented them from feeling overwhelmed, while opening the door for them to add action items to the list when needed.

During the meeting I showed the group a few pictures of “broken” signs. My favorite is a large sign that says “Caution, this sign has sharp edges”. My point is that the group in the room is responsible for making sure we don’t produce a poor end product. I asked the team to speak up or yell if they think that we are about to produce something as bad as the sign that said: “This sign not in use.”

When the broken signs tactic didn’t produce immediate results, I followed up with emails asking them to reply by the end of the next day. I then followed up with phone calls to get the information I needed.

Getting the right person involved, who was nervous enough to get others to step up, was a great step forward. Now my primary task is to keep interest and participation high.

The current project plan allows us a week to complete this pilot while fully documenting the process. We’ll have another week afterward to figure out what went wrong and what to do to fix the problems that occur. Then, we’ll do a second pilot. I’ll need the full participation of team members with that one, too.

There are plenty of abysmal statistics on failure rates of software projects, but with the right management and participation, any project can succeed. As we enter the pilot phase of our project, I am optimistic that we will continue to keep the right team in place to stay concerned and alert about the project status, ensuring a successful implementation.