Example Problem
For our discussion, we'll use a fictional yet realistic example of a problem. Meet Mariusz - owner of a (fictional) manufacturing company called “Prodmax”.
Mariusz regularly receives information from his employee – Tomek from the Maintenance Department about the lack of a tool that would improve his work. The employee complains about chaos because people report failures by email, on notes, and verbally - it's hard to effectively manage this.
You might be encountering the term "Maintenance Department" (in short, UTR) for the first time and wonder what this institution is. 😊 Well, UTR is responsible for ensuring that all machines in the company are operational and have no work interruptions.
This department is important because any downtime generates costs.
Imagine that a particular machine is not working for 8 hours - depending on what the company produces, the downtime can mean significant financial losses.
Let's return to the employee of “Prodmax”. To cope with the chaos related to reported failures, Tomek created an Excel file, which to some extent organizes all the information.
However, Tomek has one significant problem: he doesn't know what he doesn't know.
He tries to organize all the data, assigning them status, priority, etc., but in the long run, such a solution does not stand the test. Remember, we're talking about “Prodmax” - a large manufacturing company.
Considering how important the Maintenance Department is, the company owner decides to find a better solution than Tomek's Excel.
The search begins like everyone in a similar situation - by typing into Google the phrase: “Maintenance applications”. The results show several ready-made applications, but what immediately becomes apparent is that such systems have their name: CMMS (Computerized Maintenance Management System).
Browsing different applications, Mariusz notes that some of them are outdated and have an ugly interface (appearance), while others are modern and very sophisticated. This, of course, is reflected in the price lists.
Mariusz is not sure whether such an application will meet their expectations and whether his company's employees will use it.
What decisions can he make at this moment?
Purchase a subscription for a chosen cloud application and pay the subscription fee.
Ask the IT department employee to write simple scripts for Excel or Google Sheets that will automate the work.
Commission the writing of a dedicated solution from an external IT company.
No decision – maintaining the current situation of the UTR department.
Cloud products have various pricing models including:
Monthly/annual subscription.
Pay per user.
Pay per usage.
Module-based model.
One-time payment.
The application that Mariusz liked requires a monthly payment for each user. He calculated that his company needs about 10 licenses:
Pricing Model | Description | Monthly cost for 10 licenses | Cost over 10 years |
| Monthly fee for the application subscription | 1590 PLN | 190,800 PLN (1590 PLN/month x 12 months/year x 10 years) |
Pros + solutions:
Immediate use of the application after payment,
Minimal investment,
Easy to cancel if the application doesn't meet expectations without losing a lot of money.
Cons - solutions:
The risk that the application won't solve the company's problem or will solve it in a complicated and inefficient way.
In our example, the employee used Excel. One of the ideas for solving Tomek's problems with Excel is to move the file to Google Sheets and use "AppSheet".
Google Sheet with AppSheet is like "Excel on steroids". It is often used by companies to create various types of business applications, such as human resources management apps, fieldwork monitoring, warehouse management, customer management, and many others. Thanks to the capabilities of creating no-code applications, AppSheet enables the quick implementation of custom solutions without needing a team of developers.
This solution is becoming increasingly popular and has a name: "low code / no code" because it doesn't require writing new code.
Maybe it's enough to buy a course for the IT department?
Employees, after the course, should have no problem writing scripts to solve the maintenance department's problems.
Lack of automation, lack of a single database while digitizing the department (to some extent, of course).
Pros + solutions:
The cost is only the potential course for the employee and their work,
Your organization will expand its knowledge about low code, which can be applied in other departments and processes in the company.
Cons - solutions:
Time - implementing any solution will take some time (hard to say exactly how much),
There will be limitations to such a solution - certain complex things simply won't be doable.
If you haven't decided to purchase a cloud application and you're not convinced that writing your own solution will be the right choice, you might consider hiring an external IT company that will write a dedicated solution for your company.
Reasons to write a system from scratch:
Your company has a specific business process that is unique in the market and distinguishes your company from the competition,
You'd like to integrate tools to automate processes (e.g., accounting programs, banking application), and the tools available on the market don't do it,
You'd like to start utilizing artificial intelligence (AI) (in our example, automatic prioritization of faults),
You want full control over how the system works and looks.
Pros + solutions:
Support from the IT company (also after the system implementation),
A solution dedicated to a specific business process in your company,
Certainty that your problem will be solved,
Full control over the solution,
A system that will serve the company for many years and will develop with it.
Cons - solutions:
The cost of implementing a dedicated application.
Implementation time: consultations, programmers' work, tests, corrections.
No decision is also a decision. If the boss, for some reason, decides that despite certain problems, the maintenance department works well enough, there's no need to digitize everything forcefully.
"Do you, developers, have to create everything from scratch?"
Meeting a client for the first time, we often heard this pertinent and important question.
Is "from scratch" really "from scratch"?
The answer is: no.
The times when applications were written "on a blank sheet" are long gone. Nowadays, in most cases, companies use so-called frameworks or a codebase that applies basic functionalities present in most systems, such as login. You can also use ready-made libraries with user interface components.
However, the so-called business logic, which translates specific processes in the company into code, must be written from scratch. And this is the area that is the most important, should be the most refined, and tested.
The most important thing is for the company commissioning the software and the programmers to understand each other well. It's crucial to remember that the code that is created doesn't necessarily operate as the processes look, but as the programmer understood them. That's why the analysis and consultation stage is so important, so both sides understand the purpose of creating the system.