You're going to make mistakes, it's a given. In fact, making mistakes is one of the main ways you learn. Most of the time I learn more by trying to fix something I broke rather than by reading a book or website (though I frequently use those resources to help me fix what I broke).
A good supervisor will encourage you to try things out; by definition this means that you will mess up. Most of the time this trying things out will be in a test or QA environment, where it's okay to try different things. Sometimes though, you're going to be working in the production environment and at least once you will break it or destroy some data or do something that shouldn't have been done.... So what happens when you make a mistake in production?
Real world example:
One day when I was a new-ish consultant I had the task of cleaning up some RFx's in SRM. This required me to identify the RFx's that needed to be closed, and then go into the SRM front end portal and actually click the "Close" button. This wasn't as easy as it sounds. The tables in SRM, from which I had to pull data to identify the RFx's I needed to close, are all connected by something called a GUID. A GUID is a very long alphanumeric string that is 32 characters long. I pulled a bunch of data from various tables, dumped it into Microsoft Excel and started matching the data up by the GUID's and filtering out the RFx's I didn't want to touch. This Excel workbook where I was performing my analysis soon had many tabs and formulas linking all over the place trying to identify the proper RFx's to close.
Somehow, as I was actually clicking the "Close" button in the portal and marking off the RFx's I closed I started looking at the incorrect list. Instead of looking at the list of RFx's to close, I was actually looking at the list of RFx's that needed to stay open, and I was closing them! At this client, the users could be working on an RFx for up to 90 days before they published it; a lot of time and effort went into these RFx's and they could be very complex, and I just blew their hard work away!
I was still pretty new at this point, and even though I knew I wasn't going to get fired, that was still the first though that popped into my head. It was also a big hit to my ego; I'm a pretty detail oriented person, and the fact I didn't pay attention to detail was hard to swallow.
It was at this point I had to decide which course of action to take. As I saw it I had two options:
1) Say nothing, pretend it didn't happen, and when the end user eventually figured it out and they said "why is your user name in the change log for this RFX for closing it", deal with it then. Or
2) Own up to it.
It wasn't too hard of a decision for me, I swallowed my pride, took my Team Lead aside and owned up to it. To be honest, I think he found it slightly amusing at how worried I was. What my Team Lead told me next has stuck with me to this day, "Corey, I don't care that you make mistakes. What I care about is that when you make a mistake, you put in the work and fix it."
This was a standard he held everyone to, and a standard I have strived to hold myself and others too ever since.
As another example: a much more senior member of my team was using an LSMW to update some data on the PR table (EBAN) in ECC. Well, something went screwy with the LSMW and a bunch of data went haywire. This guy spent 3 very very long days fixing it and restoring the data. He made a mistake, and he fixed it.
I learned three big lessons from this:
1) When it comes to data analysis in Excel, use the KISS method whenever possible.
2) Mistakes are okay, as long as you put in the time and effort to fix it.
3) Sometimes it's worth it to take some time at the beginning and think about what you need to do, rather than just jump right in and start doing.
Cautionary warning:
In my example, it ended up being okay. The users were able to fairly quickly create new RFX's. They were okay with it because they were informed what happened. They didn't just log in one day and see their RFx's were closed for no apparent reason.
In the example of the senior member of my team who messed up the EBAN table-he ended up taking some heat. His mistake was bigger, it had a bigger impact on the business operations, it had higher visibility and it went higher up the chain of command; however, he still owned up to it, he still fixed it. He delt with the consequences of his actions professionally. He owned the mistake and the solution, and he was respected for it.
Just because you own up to your mistakes doesn't mean there will be no adverse consequences. There may well be and that's something you need to be prepared to accept. Just don't let the "someday may happen" possibility stop you from learning, trying new things, and doing your job.
Moral of the story:
It's not that you make a mistake that matters, it's what you do after that really counts.
Disclaimer:
All views in this blog are purely my own, and in no way represent, explicitly or implied, the views of my previous or current employer. While I honestly believe that what I've shared will help you, I can't guarantee that it will get you that promotion or make your boss like you.
