How can I deal with a frustrating situation at work?
June 23, 2004 7:13 PM Subscribe
How can I deal with a frustrating situation at work? (More inside, natch.)
We just started a month-long integration test for my employer's SAP implementation. It's a massive shift for most everyone in the company, as they've been using older, non-integrated systems, to manage workflow and apparently SAP is very different (and possibly evil, but I think MS Access is more actively malevolent than SAP is).
One of the people on my team is someone who is having a very difficult time testing the system--for example:
We need to create templates for capital projects and we were supposed to bring design area (a number used to identify a space, usually a building) information with us, and we were given a list of official type work categories (a subdivision of the design area) two months ago. Yesterday, this individual was complaining that none of the design area numbers that they wanted to use were in the system--even though all site data was loaded before the last round of testing--and neither were the type work categories. It turned out that this person was using a very old document from 6 months ago with dummy data, because they never quite grokked that they were supposed to use data from their home location, even though they were told repeatedly before, during, and after the last round of testing that they needed to use such information when creating templates.
A long winded example, but this is typical of this person's general behavior--doesn't pay attention to instructions and has an apparent inability to recognize that data is incorrect.
This is our third round of testing and we had a training class before we started any testing, so there's no real reason why things still haven't sunk in. What can I do to still be polite and helpful and maintain a good working relationship with this person? It's only day 3 and I'm already finding myself getting snappish.
We just started a month-long integration test for my employer's SAP implementation. It's a massive shift for most everyone in the company, as they've been using older, non-integrated systems, to manage workflow and apparently SAP is very different (and possibly evil, but I think MS Access is more actively malevolent than SAP is).
One of the people on my team is someone who is having a very difficult time testing the system--for example:
We need to create templates for capital projects and we were supposed to bring design area (a number used to identify a space, usually a building) information with us, and we were given a list of official type work categories (a subdivision of the design area) two months ago. Yesterday, this individual was complaining that none of the design area numbers that they wanted to use were in the system--even though all site data was loaded before the last round of testing--and neither were the type work categories. It turned out that this person was using a very old document from 6 months ago with dummy data, because they never quite grokked that they were supposed to use data from their home location, even though they were told repeatedly before, during, and after the last round of testing that they needed to use such information when creating templates.
A long winded example, but this is typical of this person's general behavior--doesn't pay attention to instructions and has an apparent inability to recognize that data is incorrect.
This is our third round of testing and we had a training class before we started any testing, so there's no real reason why things still haven't sunk in. What can I do to still be polite and helpful and maintain a good working relationship with this person? It's only day 3 and I'm already finding myself getting snappish.
Politness and helpfulness can still be a plus, but I'd personally sic the ol' paper tiger on the guy.
Point out the discrepencies with a supervisor, along with any other IT Staff assigned to the project. Mention the need for better documentation, as well as the importance of updating server logs. Stress the administrative responsibilites of your employers to ensure these protocols are followed, as further problems will impede workflow enough where the matter of the legacy systems will be the least of your concerns.
posted by Smart Dalek at 7:28 PM on June 23, 2004
Point out the discrepencies with a supervisor, along with any other IT Staff assigned to the project. Mention the need for better documentation, as well as the importance of updating server logs. Stress the administrative responsibilites of your employers to ensure these protocols are followed, as further problems will impede workflow enough where the matter of the legacy systems will be the least of your concerns.
posted by Smart Dalek at 7:28 PM on June 23, 2004
Response by poster: No. I'm a long-term contractor and this person has been around for 25 years and isn't a bad person. Just in over their head, IMO. And trying like mad to keep up and not being able to.
Part of this round of testing is to create better documentation for the end users because we all know that what we have isn't so hot. No one else is having these sorts of problems, because no one else is using the scripts for anything other than the most basic sort of reference or to jog their memory for the correct transaction code to use. My supervisor and the people in charge of the testing for our module are aware of this person's difficulties, and the business process owner and functional consultant spend a good deal of time helping this person. I also spend a good deal of time helping, in part because I am nearby and because I assisted this person during training and am seen as someone who can help.
I am well aware of what will happen if things go boom when we go-live with SAP next year, and yes, the legacy systems will be the least of our worries then.
posted by eilatan at 7:40 PM on June 23, 2004
Part of this round of testing is to create better documentation for the end users because we all know that what we have isn't so hot. No one else is having these sorts of problems, because no one else is using the scripts for anything other than the most basic sort of reference or to jog their memory for the correct transaction code to use. My supervisor and the people in charge of the testing for our module are aware of this person's difficulties, and the business process owner and functional consultant spend a good deal of time helping this person. I also spend a good deal of time helping, in part because I am nearby and because I assisted this person during training and am seen as someone who can help.
I am well aware of what will happen if things go boom when we go-live with SAP next year, and yes, the legacy systems will be the least of our worries then.
posted by eilatan at 7:40 PM on June 23, 2004
Remind the supervisor just how much they are paying for the SAP thing and how much it will cost to fix things down the road if you don't have a good test. I would hope the supervisor can find someone who can help you through the testing.
This always worked where I worked.
posted by birdherder at 7:52 PM on June 23, 2004
This always worked where I worked.
posted by birdherder at 7:52 PM on June 23, 2004
Meditation, a lot of deep breaths and pauses before speaking, and a constant inner voice reminding you that likely you have been and will be again a challenge for someone else to work with.
And if you do snap, be ready with an apology. Mentally you'll know that you're only apologizing for snapping, not for him not deserving being snapped at.
And then there's alcohol.
posted by dness2 at 8:04 PM on June 23, 2004
And if you do snap, be ready with an apology. Mentally you'll know that you're only apologizing for snapping, not for him not deserving being snapped at.
And then there's alcohol.
posted by dness2 at 8:04 PM on June 23, 2004
I'm going through a similar problem of people "not understanding" even though they're told a dozen times. The problem is that no one cares how many times I've told them, how thoroughly I've explained it or how many "let's go through this one more time" type things I've done. They only care that the next day they can't get it working and it's my fault. So here's what I'm currently doing:
Extensive, extensive documentation. I'm writing everything down and not leaving anything out. How I'm approaching it is that people only look at pictures (screenshots) and don't read, or if they do read they don't understand the "technical" language (which isn't really technical but if you've never used a computer before "Save to disk" and "Open file" can be very confusing).
Anyway I'm not in a position to fire people, nor would I want to as they people may be very good at their jobs but very bad with the computers we're forcing on them. I think my situation is very similar to yours now that I think about it.
Another trick I'm doing besides documentation (and documenting every phone call, this is to cover your ass when the eventual shit hits the fan, so that you don't get in trouble. A lot of people view computer related people as anti-social and not helping, so document that you did tell them to do that, and if they said at the time the issue was resolved).
If you can, try to add some redundancy and error checking. Force this guy to look at the numbers and check. I've found that if there's more then one way to do something, users respond better now that they have an option, even if the other option is worse than the first. It's all relative. I don't know how this would be done in SAP but if you can show him a different way or a way to check his data then go for it.
And plan to get frusterated and stressed. It became so bad this week that I couldn't keep down meals and had a real bad stomachache whenever I ate. It's very frusterating when you try so hard and you get things accomplished you never thought you could only to hear a "yeah it's still not working". At that point take into the possibility that this guy may not want to learn the new system. Maybe he's hoping (consciously or not) that if he screws up enough that he won't have to use SAP, or something will get changed.
I hope my trials and tribulations have helped. Just remember the key steps of making sure his performance does not fuck you over. Save your job first. Then try to attack it from different angles and give options. That whole locus of control in psychology is true even if it's a stupid other option, it's another option. And the last option is to consider that he is against change/stupid/just doesn't want to do his job. If it gets the point where you're beyond frusterated go to the supervisor with the documentation of everything you done and ask for help. Don't say "He's not getting it" but phrase it more like "Look at all I've done to help him, he's not getting it and I'm out of ideas, please help". If the supervisor is any good he/she will most likely take care of the problem without you.
posted by geoff. at 8:28 PM on June 23, 2004
Extensive, extensive documentation. I'm writing everything down and not leaving anything out. How I'm approaching it is that people only look at pictures (screenshots) and don't read, or if they do read they don't understand the "technical" language (which isn't really technical but if you've never used a computer before "Save to disk" and "Open file" can be very confusing).
Anyway I'm not in a position to fire people, nor would I want to as they people may be very good at their jobs but very bad with the computers we're forcing on them. I think my situation is very similar to yours now that I think about it.
Another trick I'm doing besides documentation (and documenting every phone call, this is to cover your ass when the eventual shit hits the fan, so that you don't get in trouble. A lot of people view computer related people as anti-social and not helping, so document that you did tell them to do that, and if they said at the time the issue was resolved).
If you can, try to add some redundancy and error checking. Force this guy to look at the numbers and check. I've found that if there's more then one way to do something, users respond better now that they have an option, even if the other option is worse than the first. It's all relative. I don't know how this would be done in SAP but if you can show him a different way or a way to check his data then go for it.
And plan to get frusterated and stressed. It became so bad this week that I couldn't keep down meals and had a real bad stomachache whenever I ate. It's very frusterating when you try so hard and you get things accomplished you never thought you could only to hear a "yeah it's still not working". At that point take into the possibility that this guy may not want to learn the new system. Maybe he's hoping (consciously or not) that if he screws up enough that he won't have to use SAP, or something will get changed.
I hope my trials and tribulations have helped. Just remember the key steps of making sure his performance does not fuck you over. Save your job first. Then try to attack it from different angles and give options. That whole locus of control in psychology is true even if it's a stupid other option, it's another option. And the last option is to consider that he is against change/stupid/just doesn't want to do his job. If it gets the point where you're beyond frusterated go to the supervisor with the documentation of everything you done and ask for help. Don't say "He's not getting it" but phrase it more like "Look at all I've done to help him, he's not getting it and I'm out of ideas, please help". If the supervisor is any good he/she will most likely take care of the problem without you.
posted by geoff. at 8:28 PM on June 23, 2004
I find that as people get older...(sorry to be an ageist here)..that they have more difficulty with technology.
This person needs someone directly to work with them (not you). They need lots of busy work practicing small things for them to learn.
So, have them input 30 items for one concept. Repeat, repeat, repeat. Small steps; let them take notes on the documentation. Essentially, they need a technology "mentor." Someone who has great patience...knows the system...and will connect the old dots to the new ones.
It's frustrating - reeducation at that level is often more expensive than other employees. Getting them onboard will make them your biggest champion ("if I can do it, anyone can")
They know you're frustrated. They're frustrated too - and feel stupid at a job they've been doing for years.
And yeah, protect your job. but it's not personal.
posted by filmgeek at 9:37 PM on June 23, 2004
This person needs someone directly to work with them (not you). They need lots of busy work practicing small things for them to learn.
So, have them input 30 items for one concept. Repeat, repeat, repeat. Small steps; let them take notes on the documentation. Essentially, they need a technology "mentor." Someone who has great patience...knows the system...and will connect the old dots to the new ones.
It's frustrating - reeducation at that level is often more expensive than other employees. Getting them onboard will make them your biggest champion ("if I can do it, anyone can")
They know you're frustrated. They're frustrated too - and feel stupid at a job they've been doing for years.
And yeah, protect your job. but it's not personal.
posted by filmgeek at 9:37 PM on June 23, 2004
Maybe just a very short checklist, so if s/he messes up again, you can (1) walk them through the checklist to identify where they went wrong, and then (2) take the checklist to document the fact that it wasn't your fault.
posted by subgenius at 9:37 PM on June 23, 2004
posted by subgenius at 9:37 PM on June 23, 2004
I suggest reducing the size of the tasks assigned to this person until you find the level of performance that this individual is capable of doing. Perhaps assign this person to something simple, like walking through examples in the documentation, creating screenshots, running sample reports. If enough low-level tasks are assigned, you can discover an area where this person can add to rather than subtract from the success of the project.
OTOH, I've worked with some "nice people who've been around a long time," and found that, as nice as they are, they just can't handle change very well. Maybe this person would be more comfortable supporting the legacy stuff until the switchover occurs.
posted by SPrintF at 9:41 PM on June 23, 2004
OTOH, I've worked with some "nice people who've been around a long time," and found that, as nice as they are, they just can't handle change very well. Maybe this person would be more comfortable supporting the legacy stuff until the switchover occurs.
posted by SPrintF at 9:41 PM on June 23, 2004
What can I do to still be polite and helpful and maintain a good working relationship with this person?
Answer his/her questions, help him/her through this situation as best you can, recommend ways s/he can brush up on the necessary info and do your best to support that.
This sounds like a very rare switchover situation. And this person may be a total boob. But unless their job is in your hands, and you see their ability to navigate a SAP migration as a key test for them, just do your job and try to make it happen smoothly.
Really, you need to think less about how stupid this person looks, and be sure not to do anything that will reflect badly on you (like bitch-slapping and calling him/her stupid in a room full of people).
It's a wee, very typical interpersonal work challenge. It's why you get paid the big bucks. Do the best you can to get through it, and your hard work will reflect well on you.
posted by scarabic at 10:04 PM on June 23, 2004
Answer his/her questions, help him/her through this situation as best you can, recommend ways s/he can brush up on the necessary info and do your best to support that.
This sounds like a very rare switchover situation. And this person may be a total boob. But unless their job is in your hands, and you see their ability to navigate a SAP migration as a key test for them, just do your job and try to make it happen smoothly.
Really, you need to think less about how stupid this person looks, and be sure not to do anything that will reflect badly on you (like bitch-slapping and calling him/her stupid in a room full of people).
It's a wee, very typical interpersonal work challenge. It's why you get paid the big bucks. Do the best you can to get through it, and your hard work will reflect well on you.
posted by scarabic at 10:04 PM on June 23, 2004
Sometimes I am really stupid. This can be helpful when trying to understand someone who seems stupid. Its 6am and I put my stupid hat on.
1) Does the person know HOW to learn the material? If not, what can you or someone else do to help them learn that? (me in my 1st language class. Duh?)
2) Some people only learn well by doing (trying) then asking questions. The connection between theory and practice won't gel until they actually sit down with it, sort of in their own 'head space'. Seems likely that something is stuck in this person's head. Possibly something basic has been missed or learned wrong. Subconciously, they are spinning wheels, and they may not even know this.
3) The mind killer, the little death: fear. Does the conversion scare this guy? A person with fears at work may put so much effort into hiding the fear that they have nothing left to deal with it. Perhaps an after-work drink and conversation might be useful to understand the problem in order to support a solution.
I am out of notions. I guess these are all rather psychological, help-the-poor-bastard kinds of things. I must be a lefty or something
posted by Goofyy at 10:10 PM on June 23, 2004
1) Does the person know HOW to learn the material? If not, what can you or someone else do to help them learn that? (me in my 1st language class. Duh?)
2) Some people only learn well by doing (trying) then asking questions. The connection between theory and practice won't gel until they actually sit down with it, sort of in their own 'head space'. Seems likely that something is stuck in this person's head. Possibly something basic has been missed or learned wrong. Subconciously, they are spinning wheels, and they may not even know this.
3) The mind killer, the little death: fear. Does the conversion scare this guy? A person with fears at work may put so much effort into hiding the fear that they have nothing left to deal with it. Perhaps an after-work drink and conversation might be useful to understand the problem in order to support a solution.
I am out of notions. I guess these are all rather psychological, help-the-poor-bastard kinds of things. I must be a lefty or something
posted by Goofyy at 10:10 PM on June 23, 2004
There is a very snotty mental image I use to keep my cool when dealing with mind-bendingly petty or inept behavior, but it works:
Imagine visiting a preschool for some reason, but you don't have a child there. Maybe accompanying a friend to pick their kid up, it doesn't matter. While you're waiting, you idly pick up a toy or something and just look at it or fiddle with it, etc. While doing this, a 3-year-old comes running up, says "MINE!" and tries to rip the toy out of your hands. At this point, you have two choices:
1) Let go, and chuckle to yourself,
or
2) Hold on tight, and say "no, MINE!"
Just let her have it. It's not worth it.
One problem with this mental upturning of the nose is that it can easily lead to condescension if you're not careful. Don't disrespect the kid, but don't pick a fight over the behavior either. Let them have the thing they irrationally want and get your job done as best you can.
Or, in other words, you can lead a horse to water, but you can't make him RTFM.
posted by ulotrichous at 11:19 PM on June 23, 2004
Imagine visiting a preschool for some reason, but you don't have a child there. Maybe accompanying a friend to pick their kid up, it doesn't matter. While you're waiting, you idly pick up a toy or something and just look at it or fiddle with it, etc. While doing this, a 3-year-old comes running up, says "MINE!" and tries to rip the toy out of your hands. At this point, you have two choices:
1) Let go, and chuckle to yourself,
or
2) Hold on tight, and say "no, MINE!"
Just let her have it. It's not worth it.
One problem with this mental upturning of the nose is that it can easily lead to condescension if you're not careful. Don't disrespect the kid, but don't pick a fight over the behavior either. Let them have the thing they irrationally want and get your job done as best you can.
Or, in other words, you can lead a horse to water, but you can't make him RTFM.
posted by ulotrichous at 11:19 PM on June 23, 2004
Brief supplementary aside. Is there some way that "legacy" means something other than old or historical? Our management use the term a lot and I've never understood the significance of it.
posted by squealy at 2:06 AM on June 24, 2004
posted by squealy at 2:06 AM on June 24, 2004
filmgeek - it's not that older people have problems with technology, it's that they have problems adapting to *change* - any and all change. It happens at different times for different people, but almost everyone hits a point where they just can't (or won't) absorb anything new. The problem is that technology is the component that changes fastest (at least here in the western world), and the rate of technological change has skyrocketed in the last century or so.
posted by Irontom at 3:31 AM on June 24, 2004
posted by Irontom at 3:31 AM on June 24, 2004
Response by poster: Legacy = old systems that are going to be replaced by SAP. All the data from these old systems is going to have to be converted into SAP (which is another nightmare, but not mine, thank goodness). Some of the systems that SAP is going to replace have been around for 20 years.
A big part of the issue, I think, is that this individual's day to day job isn't directly related to the bits of data this part of the system covers, so it's not only a matter of learning the computer system, but also all the other stuff that surrounds project management.
I think I would be less frustrated with helping this person if they didn't expect that whoever they ask for help would drop what they're doing and help immediately.
I'm not going to be blamed or held accountable for this person's success or non-success, but a database is only as good as the data in it (which is where my self-interest lies--I'm all about the data).
I think I'm just going to do my best to take it one day at a time, relax, and take a deep breath before I say anything. I can only do so much.
posted by eilatan at 4:50 AM on June 24, 2004
A big part of the issue, I think, is that this individual's day to day job isn't directly related to the bits of data this part of the system covers, so it's not only a matter of learning the computer system, but also all the other stuff that surrounds project management.
I think I would be less frustrated with helping this person if they didn't expect that whoever they ask for help would drop what they're doing and help immediately.
I'm not going to be blamed or held accountable for this person's success or non-success, but a database is only as good as the data in it (which is where my self-interest lies--I'm all about the data).
I think I'm just going to do my best to take it one day at a time, relax, and take a deep breath before I say anything. I can only do so much.
posted by eilatan at 4:50 AM on June 24, 2004
Boy, have I been there, and repeatedly. All good advice above. My elaboration:
1. At one company where there is currently an SAP rollout that took millions of dollars and still is not perfect, it's clear that the implentation is flawed because they were afraid to integrate it too tightly. I'd say more than half of their office forms--all which use the same core data, only in different ways--cannot be generated from the SAP system. There are, too, many instances where the same data has to be input in more than one place in and out of SAP. Both of these are signs that the system was not properly implemented: either someone was protecting turf and chose not to participate to the fullest extent, or the rollout folks were reluctant to intefere with hard-to-change methods and people, or the rollout was non-comprehensive for other reasons. So my advice, slightly different from above: don't let this one person (or people like him/her) affect the quality of your rollout. Cover all of your bases and do whatever you have to in order to make the SAP rollout work as well as possible. Because:
2. SAP sucks. It's an awful system which is being sold down to small companies when it is more appropriate for huge companies. For a small company, it's almost always cheaper to roll or modify your own. SAP is too expensive, too awkward, to unmodern. It's a huge waste of cash, an old-school system which is being repackaged and targeted to companies for which it is inappropriate. They make waaaaay too much money off the consulting end of the business, which is more proof to me that the product is weak.
3. At one company where we rolled out a back-office system I had problems with a key person. My job as trainer, documenter, and lead tech on the rollout was to learn every job in the company to make sure their roles, methods, and paperwork were completely duplicable by the system. I sat with them, interviewed them, came to their internal meetings. This person caused me a lot of grief by refusing to cooperate and I couldn't get her to nail down what, exactly, was the problem. In the end, she claimed it was because she didn't want to give up her three-part carbon forms on which she hand-wrote or typed information which traveled through every other department in the company. Ultimately, we got our back-office system provider to implement a brand-new (for them) method of generating the forms *exactly as they looked as carbons.* All it took was a custom SIMM module in most of our HP printers, a little extra coding, and wham, we brought that woman over to the side of the pro-rollout folks. So the lesson I learned there was: make the new system as much like the old as possible without crippling the reasons you're going to the new system in the first place. Despite the bad data management on the part of your recalcitrant person, are there any ways you can make the new system more like the old? Even just for them? It could be a matter of changing the color scheme or font of the SAP windows (I'm not kidding).
4. Another method: privilege the person. Give the person rights and responsbilities which make him/her feel more responsible, more relied upon. "I think you're about the only person here who really understands this." "I'm not sure I can trust anyone else with this." "This is going to make you a key person on our team, so I hope others don't feel left out." Etc., etc. Pride as a motivator works. I had one 60-plus-year-old woman who had a hell of a time with a terminal-based back-office system. She much preferred the old ways. But her one strength was that she could type flawlessly at about 65 words per minute. So that became her strength: I had her input a lot of needed data in a lot of different screens covering hundreds of fields. Her questions helped her learn and helped me write the how-to guide. In the end, she learned the system and all the keyboard commands. Her hands flew across the screen like a macro, because she had memorized all the internal screens and the codes which would take her there.
posted by Mo Nickels at 6:42 AM on June 24, 2004
1. At one company where there is currently an SAP rollout that took millions of dollars and still is not perfect, it's clear that the implentation is flawed because they were afraid to integrate it too tightly. I'd say more than half of their office forms--all which use the same core data, only in different ways--cannot be generated from the SAP system. There are, too, many instances where the same data has to be input in more than one place in and out of SAP. Both of these are signs that the system was not properly implemented: either someone was protecting turf and chose not to participate to the fullest extent, or the rollout folks were reluctant to intefere with hard-to-change methods and people, or the rollout was non-comprehensive for other reasons. So my advice, slightly different from above: don't let this one person (or people like him/her) affect the quality of your rollout. Cover all of your bases and do whatever you have to in order to make the SAP rollout work as well as possible. Because:
2. SAP sucks. It's an awful system which is being sold down to small companies when it is more appropriate for huge companies. For a small company, it's almost always cheaper to roll or modify your own. SAP is too expensive, too awkward, to unmodern. It's a huge waste of cash, an old-school system which is being repackaged and targeted to companies for which it is inappropriate. They make waaaaay too much money off the consulting end of the business, which is more proof to me that the product is weak.
3. At one company where we rolled out a back-office system I had problems with a key person. My job as trainer, documenter, and lead tech on the rollout was to learn every job in the company to make sure their roles, methods, and paperwork were completely duplicable by the system. I sat with them, interviewed them, came to their internal meetings. This person caused me a lot of grief by refusing to cooperate and I couldn't get her to nail down what, exactly, was the problem. In the end, she claimed it was because she didn't want to give up her three-part carbon forms on which she hand-wrote or typed information which traveled through every other department in the company. Ultimately, we got our back-office system provider to implement a brand-new (for them) method of generating the forms *exactly as they looked as carbons.* All it took was a custom SIMM module in most of our HP printers, a little extra coding, and wham, we brought that woman over to the side of the pro-rollout folks. So the lesson I learned there was: make the new system as much like the old as possible without crippling the reasons you're going to the new system in the first place. Despite the bad data management on the part of your recalcitrant person, are there any ways you can make the new system more like the old? Even just for them? It could be a matter of changing the color scheme or font of the SAP windows (I'm not kidding).
4. Another method: privilege the person. Give the person rights and responsbilities which make him/her feel more responsible, more relied upon. "I think you're about the only person here who really understands this." "I'm not sure I can trust anyone else with this." "This is going to make you a key person on our team, so I hope others don't feel left out." Etc., etc. Pride as a motivator works. I had one 60-plus-year-old woman who had a hell of a time with a terminal-based back-office system. She much preferred the old ways. But her one strength was that she could type flawlessly at about 65 words per minute. So that became her strength: I had her input a lot of needed data in a lot of different screens covering hundreds of fields. Her questions helped her learn and helped me write the how-to guide. In the end, she learned the system and all the keyboard commands. Her hands flew across the screen like a macro, because she had memorized all the internal screens and the codes which would take her there.
posted by Mo Nickels at 6:42 AM on June 24, 2004
this individual's day to day job isn't directly related to the bits of data this part of the system coversI hope you realize that this can be like plunging a high school algebra student into a differential equations class just after midterm. Not only may he not be familiar with project management, but he may not even know business process he is supposed to model.
posted by mischief at 6:47 AM on June 24, 2004
All I can do is empathize with ya, eilatan. And maybe suggest what someone else said, to get this person a detailed series of screenshots to guide them through the screens. Screenshots are great aids in SAP.
SAP sucks. It's an awful system which is being sold down to small companies when it is more appropriate for huge companies.
Guess what, it sucks bigtime for huge companies too, as SAP demands perfect data input that is not possible for a company with thousands (or tens of thousands) of raw material codes with things like scaled pricing and free sample POs and moving average prices that fluctuate legitimately. SAP is just too damn stiff and inflexible and anal-retentive for a huge company, too.
My whole job security right now is knowing how to trick SAP into doing what it's supposed to for this company, and I'm still looking for a new job, LOL.
posted by Shane at 6:54 AM on June 24, 2004
SAP sucks. It's an awful system which is being sold down to small companies when it is more appropriate for huge companies.
Guess what, it sucks bigtime for huge companies too, as SAP demands perfect data input that is not possible for a company with thousands (or tens of thousands) of raw material codes with things like scaled pricing and free sample POs and moving average prices that fluctuate legitimately. SAP is just too damn stiff and inflexible and anal-retentive for a huge company, too.
My whole job security right now is knowing how to trick SAP into doing what it's supposed to for this company, and I'm still looking for a new job, LOL.
posted by Shane at 6:54 AM on June 24, 2004
Eilatan, good for you for asking this. Very good replies above. Try to be proactive (yeah, it's an abused word) by going to this person frequently and checking in so that questions are asked when they are smaller and more manageable. That may help (both of) you deal with your frustration.
posted by theora55 at 6:59 AM on June 24, 2004
posted by theora55 at 6:59 AM on June 24, 2004
One small piece of advice from a professional computer trainer: AGREE with the guy that the software sucks. Agree with him vocally, even if you secretly love the software. Agree with him that it's hard to use, that the old way of doing stuff worked just fine, etc.
Most technophobes are scared of more than just the technology -- they're also scared of Tech People. They assume (with some good reason) that techies are going to condescend and confuse them. Techies often seem to them like an alien race. It doesn't occur to them that we also have our frustrations with machines.
I find it works wonders to spend a few minutes saying, "yeah, you're right -- wouldn't it be great if we didn't have to use this dumb program." Then, once you've worked up some rapport with the person, you can say, "oh well, since we HAVE to use it, we might as well figure out how to use it right..."
posted by grumblebee at 7:12 AM on June 24, 2004
Most technophobes are scared of more than just the technology -- they're also scared of Tech People. They assume (with some good reason) that techies are going to condescend and confuse them. Techies often seem to them like an alien race. It doesn't occur to them that we also have our frustrations with machines.
I find it works wonders to spend a few minutes saying, "yeah, you're right -- wouldn't it be great if we didn't have to use this dumb program." Then, once you've worked up some rapport with the person, you can say, "oh well, since we HAVE to use it, we might as well figure out how to use it right..."
posted by grumblebee at 7:12 AM on June 24, 2004
Response by poster: Clarification: I'm not an IT person. I'm a financial sort of person (hence my lurve of standard data, alas, it's such an illness and me a former English major!)--but because I'm picking this up pretty quickly, I've become the first line of support for this individual--mainly because I sat next to them during the training and helped. I am by no means an SAP expert. I make plenty of stupid mistakes myself. I made a couple yesterday, in fact.
We have a training manual with screenshots. Even with screenshots, this person gets lost. I'm not sure why they didn't bring the manual with them this time around. Everyone is cognizant of how difficult it is for this person, and is doing their best to help. But when, for example, the person can't locate "USER STATUS: PLAN" on the screen when it's there in plain sight because the script doesn't say precisely where on the screen it is (this is in CJ20N in PS, for you SAP folks), it's hard to not roll the eyes. But I didn't.
The main reason I am liking SAP is that it's going to aggregate our financial data in a way that will make it 50 million times easier for me to generate my monthly financial summaries. It's also going to help facilitate the account reconciliations required by Sarbanes-Oxley. This is a pretty large division of a huge company, so there's lots of data to churn.
Thanks for all the help--some good advice, and I'm glad I'm not the only person who has had to deal with this sort of thing (I know it's a small problem in the grand scheme of things, but it's like a pebble in my shoe, you know?).
posted by eilatan at 8:11 AM on June 24, 2004
We have a training manual with screenshots. Even with screenshots, this person gets lost. I'm not sure why they didn't bring the manual with them this time around. Everyone is cognizant of how difficult it is for this person, and is doing their best to help. But when, for example, the person can't locate "USER STATUS: PLAN" on the screen when it's there in plain sight because the script doesn't say precisely where on the screen it is (this is in CJ20N in PS, for you SAP folks), it's hard to not roll the eyes. But I didn't.
The main reason I am liking SAP is that it's going to aggregate our financial data in a way that will make it 50 million times easier for me to generate my monthly financial summaries. It's also going to help facilitate the account reconciliations required by Sarbanes-Oxley. This is a pretty large division of a huge company, so there's lots of data to churn.
Thanks for all the help--some good advice, and I'm glad I'm not the only person who has had to deal with this sort of thing (I know it's a small problem in the grand scheme of things, but it's like a pebble in my shoe, you know?).
posted by eilatan at 8:11 AM on June 24, 2004
Response by poster: Update: had a talk with this person after dinner, they are awfully frustrated as well and think that repetition of core concepts will be helpful (screen shots apparently would not be helpful, as I offered to get my training manual from my office), so I told them I'd talk to our team leads in the morning and see if they would be okay with me taking over some of the workload for that location so this person can spend time doing the repetition they feel they need. I'm not hugely busy with testing for my location, so I think the leads will be amenable.
Again, thanks for all the adivce--it really did help.
posted by eilatan at 7:54 PM on June 24, 2004
Again, thanks for all the adivce--it really did help.
posted by eilatan at 7:54 PM on June 24, 2004
« Older Can't sit down the chair will eat me | How can I sync my Palm Tungsten C with Mozilla... Newer »
This thread is closed to new comments.
posted by bingo at 7:24 PM on June 23, 2004