Let me tell you what a systems engineer is. Firstly, if you study the definition of a systems engineer’s role, you will be overwhelmed by the complexity and variety – is this all to be done by one person? If you read individual job advertisements like I did when a headhunter recommended me for my first systems engineering position, you will see a balancing act between development work with the in-depth expertise of a thoroughbred developer, and technical project management with broad business management and team leadership skills. So what now? In this blog article you will get a better understanding of systems engineering and hints how systems thinking helps to reduce time efforts and costs for complex systems.
Systems engineering as an unclear job title
The truth is that many people are unclear about what a systems engineer is. In essence, some interpret systems responsibility as the role of the systems engineer.
I met a commissioning engineer who refers to himself as a systems engineer in his email signature because he claims to be such an experienced technician that he now deserves to be called an engineer, like professional engineers of his company. In Germany, there is a clear distinction between educated specialists, state-certified technicians and studied professional engineers with an university degree. These titles are protected by law. So it is all the more surprising when colleagues who are educated specialists insist on using the title of an engineer – they are simply not allowed to, despite their many years of experience. I met systems engineers who had spent years developing an unrivalled Doppler lidar system on their own. I met systems engineers whose job was to perform periodic maintenance and technical documentation on systems from a third party manufacturer. I met systems engineers with pure product responsibility, with no systems integration tasks. My role as a Systems Engineer in a well known developer, manufacturer and supplier of meteorological remote sensors (mainly Radar and Lidar) is to design and deliver a solution in accordance with all stakeholder requirements such as customer, business, project management and requirements by law.
International Council of Systems Engineering (INCOSE)
In the real world of work, both the company and the employee should check their common understanding of the role description before entering into a business relationship. When the job has so many facets, a standard or reference would be helpful to avoid too much variation. Interested parties should therefore consult the International Council of Systems Engineering (INCOSE). The terminology and processes throughout the system life cycle of a system are defined and standardized. If you want to understand what terms like systems architecture, lifecycle stages, and the role and integration of the systems engineer in business processes mean, INCOSE is a good place to start. I’ll let you in on a little secret. Your counterpart will perceive you as much more competent if you can navigate the INCOSE terminology spectrum. My approach has often been questioned. However, after a simple technical reference, the dissatisfaction and questions were reduced.
Success with modular system architecture thinking
In addition to the many topics described there, you find the systems thinking approach particularly noteworthy at this point. Every system can be broken down into subsystems that can be modularly structured by their interfaces. This allows a reference design state to be mapped for each system. For individual customers or projects, this system image can be expanded or modified on a modular basis. Unfortunately, what sounds logical, economical and perfectly natural at first glance is not fully realised in practice. When I started working as a systems engineer for meteorological radar systems, I was told in the first few months that there are no standard projects and that everything is always customised. I was all the more surprised when, after three years, all the processes were so well established that, after a further two years, almost 50% of all systems delivered were derived from a reference design status. In those five years I learned one thing above all else: success in a company depends on the mindset and culture of each individual. During the company’s internal system design review, the “there are no standard systems” mantra was dropped. Imagine the feeling of being able to assemble a system design from different packages in less than 10 hours instead of hundreds of hours of design engineering – awesome. I can only recommend to everyone that with every development, every line of code, every technical document and every technical design, you should always ask yourself how you can create a generally valid set of data from the work that has been done, which is distributed decentrally throughout the company. How many times have I seen a huge amount of work done on a customer project, only to see it repeated almost identically on the next project, perhaps a year later and with different colleagues? Fortunately, I have learned early to share ideas with colleagues during coffee breaks, lunches or group meetings, and to ask the same question over and over again: Have we solved this problem before and can we derive a general rule for similar problems in the future? If you take a quickwin from this blog entry, then this one is for you! In reality this can only be established by using professional tools that support Enterprise Resource Planning (ERP) and Product Data Management (PDM). While PDM is used as an engineering data tool to manage part lists, technical documentation, engineering calculations and revision management; the combination with ERP for supply chain management, logistics management and budgeting, pricing and contracting allow a perfect combination to collaborate with huge amount of different departments effectively. Databases can be customized and combined to represent the copanies processes.
Systems engineering as a door opener
You will meet many managing directors, CEOs, department heads, freelancers and entrepreneurs with a systems engineering background. With in-depth technical knowledge and involvement in business processes and team leadership, a systems engineer is inherently qualified to take on other roles. As a result, many of my colleagues have gone on to become managers and have had really impressive careers. I have even met systems engineers who went on to become sales directors of large companies.
What are your expieriences with tasks and responsabilities of a systems engineer? I invite you to a discussion in the comments and identify the different facets that are present in the real life so that readers get a better impression.