We build a system that ties the company goal to team and individual goals and bases the end-of-period review on records rather than memory. Goal management runs on OKR and individual assessment on a performance management system (PMS); we keep the two side by side on the same platform without mixing them up.
In most companies the performance conversation is opened once a year, in December. As the manager fills in the form in front of them, they have no record built up over the year; what they remember is what happened in the last two months. Goals are scored on the same form, but often nobody has to hand exactly how those goals were written at the start of the year. The result is a score neither side believes in. If the bonus depends on that score, the argument grows; if it does not, the form soon becomes a piece of paper that only goes into the HR file, and the following year it is filled in even more carelessly. Either way the real purpose — seeing who contributed what — is lost.
Two different needs are actually tangled together here, and each has its own name. A performance management system (PMS) looks at the individual: the end-of-period review, measuring competencies, the development plan, producing input for promotion and pay decisions. OKR (Objectives and Key Results) looks at the company: setting a handful of ambitious objectives for three-month periods, tying each objective to numerical key results, and making it visible that every department is aligned behind the same priority. One is about how a person works, the other about what the company is focused on this quarter. Both are needed, but when they are mixed into the same form both break. That is why, in the system we build, the two sit in the same place but run separately.
In the structure we set up, goals sit as a tree: the company objective, the department and team goals attached to it, and the responsibilities that come down from there to the individual. Every key result must have a measurement source; wherever possible that value comes automatically from the ERP, the production tracking system, the CRM or the reporting layer, and where it has to be entered by hand, who the number came from and which document it came from is recorded. Progress is updated at short intervals within the quarter; whether a goal will be met becomes visible in the middle of the period, not at the end. On the individual assessment side, the form, the skills matrix, the notes from the conversation between manager and employee and, optionally, 360 feedback all build up in the same file. At the end of the year, whoever fills in the review is faced not with a blank page but with the record accumulated over the period.
The things this will not fix should also be said. Software does not build a feedback culture in a company where the manager does not know how to give feedback; it only makes the empty fields visible. Nor does it make unmeasurable work measurable; forcing a goal onto a contrived number usually pushes people into gaming that number. And tying OKR directly to bonuses is the most common mistake made, despite the method's own warning against it: the moment a bonus is attached, nobody writes a difficult goal. Our recommendation is to keep OKR as a tool for focus and alignment, to feed the bonus and promotion decision from a separate assessment, and to build that separation into the system. You make the decision; our job is to keep the record the decision rests on clean.
Where the shop floor runs but the office side has grown, and who is responsible for what in sales, planning, purchasing and accounting can no longer be tracked by word of mouth. At this scale, having the goal in writing is valuable because it lowers coordination costs rather than headcount. The first concrete benefit is usually not scoring but expectations becoming clear.
Sales, field and dealer teams already have targets, but they usually sit in an Excel file and become a subject of argument at the end of the month. When the source of the target, progress within the period and the calculation are visible to everyone on the same screen, most end-of-month objections are cut off at the start. How the target is calculated is written into the system; it does not stay in a verbal agreement or a personal file.
Companies moving from a structure where decisions are made at the owner's desk to one of departmental responsibility. The hardest thing in that transition is not delegating authority but defining how the delegated work will be measured. A goal and assessment system puts that definition in writing; the handover rests on ground that can be discussed and audited. It also creates a common language between an incoming professional manager and the family members.
Software, engineering, agency and consultancy work, where the output depends on projects. OKR settles naturally into these structures, because quarterly goals and the idea of focus match the rhythm of the work. Individual assessment is then fed from project records and feedback. Resource utilisation and project profitability are the job of a separate system.
The company objective, the department and team goals, and the responsibilities that come down to the individual all sit in a single tree. Every goal has a defined owner, period and method of measurement. When an employee looks at their own goal they see which company goal it is attached to; the manager watches all the work under that same goal, and its owners, on one screen. Who has not yet written their goal at the start of the period is also visible on the same screen.
For teams that want to work with the OKR method, an objective and key result structure is set up; every key result is required to be numerical and verifiable. Progress and confidence level are updated at short intervals within the quarter. At the end of the period, whether the goal was met and why is put on record. If the company does not want to use OKR, the same structure can be built with classic goal and KPI logic.
Key result and KPI values are pulled automatically from the ERP, the production tracking system, the CRM or the reporting layer as far as possible. For values entered by hand, who entered the number and which document it was based on is recorded. A target figure of uncertain origin is where the argument starts at the end of the period; that is why defining the source is mandatory. If a measurement has no source, the gap is flagged before the goal is approved.
Review forms open in line with the period calendar; manager and employee fill them in separately, after which the notes from the conversation are added to the same record. A calibration screen comparing how harshly different managers score makes unfairness between departments visible. Past periods can be opened for comparison. The review calendar, reminders and overdue forms are tracked from the HR dashboard; nobody has to chase people by email.
Optionally, feedback is collected from colleagues, internal customers and direct reports; who answers which question is defined by management and anonymised where necessary. Short feedback notes can also be recorded throughout the year. At the end of the period the review is fed from that accumulation, not from the memory of the last two months. Feedback questions are written in the company's own language; you are not obliged to fit a ready-made template.
The competencies expected for each role are defined and the review result is written into that matrix. Gaps that emerge are tied to a development plan and, where needed, to a specific course in the learning management system. The review therefore does not end with a score; each period produces a next step that can be followed up. The development plan is followed with reminders during the period rather than being left to the end of the year.
The review result, goal achievement and competence status are produced as a single summary for the bonus and promotion decision. The bonus calculation itself is done in the timekeeping and incentive system; what is produced here is not the calculation but the decision it rests on. The decision history is stored with its rationale, in an auditable form. If there is an objection, which data went into the decision can be shown retrospectively.
We discuss where goals are held today, the bonus rules, the review calendar and what has not worked in past periods. HR, the relevant department managers and senior management sit at the same table. In this session it often emerges that the company goal has never been written down at all; that is usually where the work starts. We also decide together at this stage which information will be open to employees.
The goal structure, the length of the period, where OKR and individual assessment will be separated and which system each measurement will come from are designed in writing. Measurements that cannot be fed automatically are flagged and the rule for manual entry is set. The design phase usually takes between three and six weeks. The output of the design is a short document put to you for approval before any software is written.
We start with a single department and a single quarter. The aim is not to test the software but to see that goals really can be written and measured. Some of the goals written during the pilot turn out to be unmeasurable; correcting these early is the most productive part of the project and has to be done before roll-out. It is more instructive to choose as the pilot the area where goals are hardest to define, rather than the one where they are clearest.
End-of-period review forms, the calibration screen and optional 360 feedback go live. Managers are shown how to fill in the form and how to run the conversation; without that transfer, even a correctly built system fills up with empty data that is identical from one person to the next. In the first period we join the calibration meeting as well and support the flow as it settles.
Scope is extended to the other departments, and the period calendar and reminders are settled. The system is handed over to the team: how goal templates are updated, how a new measurement source is connected and how the period close is run are left in writing. At the end of the first full period we review the model together. We stay with you until opening and closing a new period becomes work the team can run on its own.
They are not, and confusing the two is the most common mistake in this area. OKR is an alignment tool that shows what the company is focused on in a given period; the objectives are ambitious, they are not expected to be met in full, and their real function is to pull teams behind the same priority. A performance management system, on the other hand, looks at the individual: competence, contribution, development needs and input to the pay decision. Squeezing the two into a single form penalises writing ambitious goals and quickly turns OKR into an ordinary task list. That is why we keep them on the same platform but run them separately.
Technically we can, but we do not recommend it and we say why plainly. The moment a bonus is attached to a goal, the person writing the goal starts writing what is achievable; the method itself gives this warning. In the end you lose your ability to produce ambitious goals and are left only with goals that are easy to hit. Our recommendation is to feed the bonus and promotion decision from the individual assessment, and in directly measurable work such as sales and production from separately defined bonus rules as well. Even so, if you want to link them we will build it; we will share in writing that the decision is yours, and what the risk is.
It can, but in most plants we do not recommend it. An operator's output depends largely on the speed of the line, the job given that day, the state of the machine and the material coming in; writing that down as the individual's performance is both wrong and a result that loses trust on the shop floor. On the blue-collar side, fairer and more defensible measures are attendance, competence and document validity, quality records and health and safety breaches. We take these from the timekeeping, quality and training systems and display them; we do not score a person by the speed of the line.
It will not. If you have a system that does the bonus and timekeeping calculation, it stays where it is; the calculation that goes to payroll carries on being produced there. The system on this page produces not the calculation but the decision the calculation rests on: goal achievement, review result and competence status. A connection is made between the two sides, so that when the bonus period comes the data is not carried across by hand and two different figures do not appear in two places. Which side produces which figure is set out in writing at the start of the project.
Access is defined by role, and that definition is made in the first sessions of the project. The general rule is that a manager sees only their own team's records, HR follows the process as a whole, and senior management works with a summary and calibration view. Whether it will be visible who wrote what in 360 feedback is decided at the outset; if it is to be collected anonymously, it is genuinely collected anonymously. Performance data is personal data; retention periods, access logging and deletion rules are designed together with the compliance side.
A goal tree running from the company down to the individual; quarterly objectives and key results run with OKR; progress tracking whose measurements are fed automatically from source systems as far as possible; periodic review forms, a calibration screen and optional 360 feedback; a skills matrix with a development plan; a summary report that produces input for the bonus and promotion decision. The source code and all the accumulated data belong to you.
In a 30-minute discovery call we listen to what you need and tell you honestly whether custom development or an off-the-shelf product is the better answer.
We do not replace Logo, Mikro or Netsis (the accounting packages in common use in Türkiye). We build a finance layer that gathers current accounts, banks, cash, cheques and promissory notes, expenses and cash flow alongside your accounting package, and puts collection, payment and approval processes on rules. The record is still kept in accounting; visibility and process run in this layer.
Details →We move the budget out of Excel files and into a system that is versioned, has a named owner and is compared with actuals automatically. When the month closes, the variance report is not put together by hand; the reason for the variance is recorded, the forecast is updated and the management pack is produced from the same numbers. The goal is not more reports, but seeing where you stand against target in a single figure nobody disputes.
Details →On legacy systems with no API, we build software robots that take over the repetitive steps a person performs on screen. The robot runs under its own user account and on a schedule; when something unexpected happens it does not guess, it stops and hands the job over to a person along with a screenshot.
Details →We build an inventory of your processes, map them as they really are using BPMN 2.0, and define an owner and a measure for each one. We then run them on a process engine (BPMS) and measure cycle time, waiting points and bottlenecks. If a single flow is all you need, we will say that plainly too.
Details →We build the layer beneath the report: data is pulled from source systems by ETL or ELT, modelled across raw, processed and presentation layers, and stored together with its history. Metric definitions are fixed in a single data dictionary, and quality checks catch silent corruption while the data is still being loaded.
Details →We repair the record-keeping in which the same customer has been created three times and the same material sits under two codes. With matching rules, a similarity score and a review queue, duplicate records are deduplicated, a golden record is produced and distributed back to the source systems, and a similar-record warning steps in whenever a new record is created.
Details →
