BCS from project costing to invoicing

Flexus has been on the market since 1995. We started as a consulting company with three employees. In 2001, Flexus became a stock corporation, with around 20 employees at the time. From 2009 onward, we increasingly focused our business on standardized SAP add-ons. Today, we have grown to more than 100 employees.

We see ourselves as a family-run company, product manufacturer, license vendor, and consulting firm for SAP intralogistics. Our focus is the entire material flow — from inbound to outbound: yard management, deliveries, goods receipt, warehousing, production logistics, picking, loading, and shipping.

Our customers come from a wide range of industries and company sizes — from large industrial enterprises to smaller customers. What they have in common is that they face logistics challenges, which we solve with consulting, control, mobility, and automation.

For us, this business means that our internal processes are highly diverse. We do not have just one project model, but many different types of services, contracts, and billing models. That is why it was essential for us to introduce a system capable of mapping this broad range.

Evolved system landscape, growing requirements

We advise large companies on all aspects of SAP. SAP is very powerful in many areas, especially in materials management, warehousing, and as a central data foundation. However, specialized tools are required to manage a project-based service business with project costing, time tracking, resource planning, controlling, and invoicing.

Our internal system landscape had grown over many years. We had developed our own solutions, including FlexHub for time tracking and other internal processes. In addition, we used systems and repositories such as SharePoint, Teams, Outlook, Word templates, OneNote, Planner, Zammad, Jira, Git, HubSpot, and DATEV.

Each of these solutions served its purpose. At the same time, media discontinuities emerged between sales, project management, service delivery, and invoicing. In addition, every custom development ties up internal capacity. Development time spent on internal tools is not available for customer projects and product development.

That is why we defined a clear premise for the introduction of BCS: no more new custom developments for internal processes. Where it makes sense, we adapt our processes to the BCS standard instead of developing individual custom solutions again.

First, we have new time-and-materials projects. These are billed in the traditional way based on time and resource usage. For this, we need clean time tracking, clear hourly rates, and a reliable assignment of services to the project.

Second, we have new fixed-price projects with milestones. Large customers in particular often request fixed prices. Internally, however, we still need to know exactly which times and efforts are incurred in order to assess profitability.

Third, we handle change requests for existing customers. These are often smaller, fast-moving processes. Here, we need to be able to create quotes quickly — sometimes within 24 to 48 hours.

Fourth, we have support and maintenance. This may sound simple at first, but in practice it is complex: contracts change, terms need to be taken into account, and services must be billed on time.

Fifth, we have subscriptions and subscription-based models. In the past, we focused more on selling licenses. Today, there are monthly and annual billing models, different payment models, free trial periods, and varying contract terms. This creates many variables that we need to manage properly.

Sixth, there is our internal development. We develop our own products, with teams working on them continuously. One example is our transport control system, which moves millions of pallets every year. These projects also require planning, costing, resource management, and controlling.

Seventh, there are internal organizational projects. Internally, too, we have change, management, and structural projects. These should not run incidentally through emails, lists, or individual tools, but need to be managed in a traceable way.

For us, it was therefore clear: We need a system that can map time-and-materials projects, fixed prices, milestones, change requests, support, maintenance, subscriptions, product development, and internal organization in one shared structure.

First: clear boundaries. We do not further develop BCS ourselves. Change requests are submitted to Projektron as change requests. Our own developers should work on our products and customer projects, not on internal BCS custom solutions.

Second: discipline. We initially adapt to the solution and are willing to adjust our ways of working to the system’s conditions to a reasonable extent. In the first quarter, we did not want to implement any change requests, but rather document, understand, and gather experience.

Third, we rely on governance. A key user team with a spokesperson manages further development and reports directly to management. In addition, we work with fixed budgets per half-year. This keeps further development controlled and focused.

The project structure is currently the core element of our BCS usage. We have around 180 active corporate groups and customers, 580 project groups, and about 3,400 projects and 300 subprojects in BCS. Building this structure cleanly during data migration was challenging. In the end, however, we succeeded in creating a reliable foundation.

We created templates in BCS for our different project types. In the process, it became clear that introducing such a system is also an organizational learning process.

Our first templates were very detailed. In practical use, however, it became apparent that too many specifications can limit flexibility. That is why the templates are now becoming leaner, more flexible, and more closely aligned with actual needs.

In costing, we can take structure plans, schedules, effort plans, and utilization into account. This allows us to assess earlier which resources are needed and how a project is likely to develop.

At the same time, one thing is clear: the quality of costing, project management, and controlling depends heavily on data maintenance. BCS provides the foundation, but the data must be maintained consistently and carefully.

Time tracking, expenses, and project management

We record and manage time tracking, vacation, sickness absences, and expenses in BCS. Previously, we had our own tools for this. These were highly tailored to our requirements, but they also had to be maintained and further developed internally.

BCS is more standardized in certain areas, but it offers us the advantage that it can be used universally for many processes and for all employees. International expenses can also be recorded without requiring custom developments.

Time tracking is also the basis for project controlling and billing. For time-and-materials projects, it flows directly into invoicing. For fixed-price projects, it serves internal controlling purposes in order to assess profitability and resource usage.

In project management, we use various plans and views, such as the structure plan, team plan, effort plan, and order plan. At the beginning, this required orientation and onboarding. By now, the teams have defined their own filters, views, and column configurations that fit their respective ways of working. Views can be saved and shared.

More than 20,000 tasks have been created in BCS, around 1,300 of which are open. This shows the importance BCS now has in day-to-day operations.

Invoicing was one of the key reasons for introducing BCS.

We bill a wide range of services: time-and-materials services, fixed-price projects with milestones, licenses, subscriptions, maintenance, support retainers, tickets, travel expenses, on-call times, and surcharges.

In BCS, accounting data, customer data, invoice templates, function rates, projects, bookings, and accepted quotes all come together. As a result, total costs, material costs, and personnel costs can be shown more clearly.

Invoicing becomes more transparent and better prepared. Even smaller units, such as half hours, can be billed cleanly. At the same time, roles and responsibilities in the process become clearer: project managers review bookings on the project, business unit managers review expenses and travel times, and invoicing then works on the basis of prepared data.

Recurring services are a particularly demanding area. In addition to traditional license models, monthly and annual subscriptions, maintenance and support retainers, and other recurring models are becoming increasingly important. This creates numerous variants: payment models, free trial periods, contract terms, notice periods, start dates, and billing periods. In the long term, these topics cannot be managed reliably through individual knowledge, reminders, or isolated lists.

BCS helps us standardize these commercial requirements more effectively. Deadlines, items, billing periods, and follow-ups can be mapped in a more structured way. At the same time, we still see further optimization potential in this area.

Accounting continues to be handled in DATEV. BCS prepares the relevant data and exports it toward DATEV.

BCS in our system landscape

BCS is not the only system we use. HubSpot remains our CRM. Jira and Git are established for software development and product planning. We use Zammad for support. In addition, we use a wiki, helpdesk, Planner, OneNote, Teams, Outlook, and DATEV.

Our approach is to continue developing the system landscape step by step and based on clear benefits. Not every function has to be mapped in BCS in the short term. At the same time, we are reviewing which processes can be meaningfully integrated into BCS or moved there in the long term.

What matters is that every integration and every replacement has a clear benefit. We want to consolidate the system landscape without creating new complexity.

Next steps

As next steps, we are reviewing several topics: the integration of Zammad, the replacement of the internal helpdesk with BCS, the long-term role of Jira, better reporting for management and teams, and AI-supported data analysis.

Reporting in particular is important to us. We want to see more clearly where projects stand, which services are billable, how utilization is developing, and where action is needed.

Assessment and conclusion

From the management’s perspective, the introduction of BCS was an important step. We did not simply introduce a new tool; we restructured a significant part of our internal value creation.

Previously, we had several functioning but distributed solutions. Today, we bring master data, projects, costings, quotes, orders, times, expenses, and invoicing information together more closely. This reduces coordination effort, improves traceability, and creates a more consistent basis for operational and commercial decisions.

At the same time, the introduction was — and still is — a learning process. We had to clean up data, create project structures, adapt templates, clarify roles, and establish new ways of working. BCS delivers its greatest value when processes are implemented with discipline and data is maintained consistently.

This path suits us because we have consciously decided not to build new internal custom developments. We want to invest our energy more strongly in customer projects and product development. BCS provides us with a standard platform that is broad enough to map our day-to-day business.

With BCS, we have significantly standardized and integrated our project, service, and billing processes. This makes BCS far more than a project management tool: it is an ERP system for our project-based service business and an important building block for combining growth, transparency, and commercial control.