How I Optimized a Department and Made Enemies Instead of Getting a Bonus
A cautionary tale from 2010 about a 1C developer who automated two labor-intensive processes in a finance department, only to be betrayed by the very people he helped when they realized the efficiency gains threatened their job security.
I continue the series of articles from the days of yore.
I recently ran into a former colleague and he reminded me of this story, which I had completely forgotten. Not the lesson itself, but just the incident.
2010: due to family circumstances, I found myself in a deep financial crisis. I didn't even have money for gas. An acquaintance offered me a job as a 1C specialist at their company. The pay was modest (compared to the market). I agreed to work there for a few months until I found a proper position — that was the original arrangement. The 1C department had 3 people, and I became the fourth.
Everything described below didn't happen on the first day or within a single month, of course. I was simply gradually immersing myself in the atmosphere of the team and the organization.
They had this finance department there that considered itself oh-so-very important. Not in terms of actual usefulness, but in terms of positioning. They puffed up their cheeks, saying "without us, you'd be nowhere. We're the real specialists here." Fine by me — they were at the other end of the building, and I never crossed paths with them. But I heard colleagues discussing them.
That department had 4 people. One of their tasks was adjusting pennies in invoices so that the line items matched the total amounts. You know about rounding. For this, they had an entire tool — a document in 1C with prices going to ten-thousandths of a kopeck. They sat there manually adjusting tenths of kopecks. This process was legendary. It was considered impossible to automate — everyone who tried had failed, or so my boss told me.
How can that be? That's impossible! I don't believe it! Show me!
They showed me how it was done — what they clicked and what they compared. I went back to my desk and started experimenting. I don't remember exactly what the trick was. Either the prices in the lines originally had ten-thousandths of kopecks, or something like that. But the printed invoice showed a total amount to the second decimal place — 80.35 rubles, not the fourth — and it was precisely this amount (to the second decimal) that needed to match.
After thinking over what I'd seen, I wrote a loop that first calculates the difference between the total amount of 80.35 rubles (which cannot be changed) and the direct sum of the line items.
80.35 - (50.2500 + 30.0900) = 0.0100The loop's job was to exhaust the entire difference by distributing it across lines. Proportional distribution wasn't required. So I added the maximum possible value to each line until the difference was exhausted.
80.35 - (50.2590 + 30.0910) = 0.0000If for some reason the difference couldn't be distributed, a corresponding warning was displayed, which was also written to a log. I wanted to see if there were cases I hadn't accounted for. But the few entries that appeared in the log only indicated errors at the data entry stage, and after correcting those, the distribution worked fine.
They were happy, and I was puzzled — why hadn't anyone done this before? It was so simple...
The Cherry on Top
That was the backstory. While communicating with that department — asking about the kopecks and observing how the solution worked — I thought I had conquered their biggest problem. But according to them, that was just the beginning. The biggest problem was actually at the data entry stage. They needed to enter incoming document and payment numbers into invoices. They did this manually — they'd take a bank statement, primary documents from suppliers, and start matching. Back then, the culture of correctly specifying payment purpose wasn't well established, so (among other reasons) they had to sort everything by hand. They sat buried in mountains of paper, marking processed documents with pencil and moving them to a neighboring stack. You get the picture.
So I conducted another survey, this time about this process. Where they got the data, where they entered it, how they matched one thing to another, why exactly that way and not another, what they did when numbers didn't match, and so on. I noticed that supplier invoices had barcodes on them. I went to a neighboring department and begged them for a scanner (they had a couple dusty ones lying around). I scanned one and saw that it contained the number and date.
The picture came together, and I built them a workstation application where only documents requiring attention were displayed. The system itself suggested matching options or auto-filled incoming numbers (where needed); all they had to do was scan invoices from the list and confirm or correct the payment matching. Debugging took several days because details emerged that they hadn't mentioned earlier. In any case, I fixed things on the fly. After a couple weeks of debugging, the workstation ran like clockwork. What used to take three of them several hours daily could now be done by one person in 10 minutes. They were happy again. They said, "Now we can work at a calm pace and not sit here until midnight. Now we have time for a cup of tea."
My boss was aware of this work and watched with interest. After the final version, I went to him and said that, well, you know... a bonus would be appropriate here... He completely agreed (we had discussed it in advance) and went to the director for approval. The director didn't seem to object either, but asked for written confirmation from that "happy" department that things had indeed improved so much.
And that's when it all started. They figured out what this could mean for them (layoffs) and decided to completely slander me. They said the workstation was total garbage, that nothing worked, that it was some incomprehensible creation, that they didn't use it and never asked me to build it. My boss went to them asking — how can this be, you said everything was fine... They pounced on him too; there was screaming throughout the entire corridor... As a result, my boss came back to me looking defeated and said, "Sorry, I did everything I could" (and that's true — I have no complaints about him).
So not only did I end up without a bonus, but I also made enemies. Fortunately, I didn't have long left at that company. About two weeks later I received an offer and left.
And some time later, a junior developer came along and accidentally broke something in the code — the workstation stopped working.
But the "happy" department "didn't use it," so they couldn't come and say the workstation was broken. And thus justice prevailed without my involvement.
By the way, yes, this is the same company where the modbus story happened.
Now, when someone asks me to talk about a failed project and what I'd do differently, I know what to tell them :)
Have you had similar experiences? Share in the comments.
P.S.
Be careful with automation. That is the lesson I took from this story — but not at the time; only years later. I almost destroyed people's lives.
Back then, for me it was just another achievement for the collection, but for them it could have turned into a tragedy.
FAQ
What is this article about in one sentence?
This article explains the core idea in practical terms and focuses on what you can apply in real work.
Who is this article for?
It is written for engineers, technical leaders, and curious readers who want a clear, implementation-focused explanation.
What should I read next?
Use the related articles below to continue with closely connected topics and concrete examples.