Posted by Swarf, Mostly! on 09/10/2022 20:07:15:
Posted by John MC on 09/10/2022 15:31:01:
SNIP!
Something else, what is "systems engineering". Never got an explanation but at one time it was a big "thing". Best explanation I got was that "it was something good engineers have always done".
John,
It seems that if you ask this question to, say, a dozen different companies or organisations, you'll get at least fourteen different answers.
I think the problem here is that because it's about a way of thinking, there's very little to tie disparate users to a common ground.
My experiences of "Process Systems Engineering" are very different from my old housemate's experiences as a "Systems Engineer" for a software company who provided vibration analysis tools for aerospace and automotive clients…
The only thing that I've been able to use to tie all the different "Systems Engineering" definitions together, is that at the core there's a focus on:
- modelling complex systems based on an input of limited datasets,
- validating that model within a given parameter space,
- then using the model to optimise some output.
In turn that points to a heritage in "Operations Research" (which could be described as using statistical techniques to make better decisions about systems which are too complex to understand intuitively).
I have also heard systems engineering (facetiously, but not inaccurately) described as:
- "Engineering your engineering, so your engineering can be engineered."
Which is kind of a consistent explanation when you hark back to the heritage in operations research; it just seems bizarrely "meta" to talk about designing a design process.
Here's what I used to answer when I was asked the question:
If, as the (development) project progresses, either the hardware development engineers or the software writers suffer a moving goalpost, then the Systems Department haven't done their job properly in drafting the design specifications. You don't start the development until the customer has read and signed those design specifications.
I would tend to agree with your definition with respect to a large capital project (say a chemical plant, or a bridge), or a one-off order for a highly specialised product (like a jet-fighter or a ship).
But the waters have been badly muddied here by the rise and rise of products not linked to anything corporeal, and the rise of various "Agile" development approaches coming out of the IT sector (where they work pretty well in the whole) in which the point is that you assume the goalpost is always moving and always will be, so constantly re-appraise the direction of your work, so as to have any chance of hitting it at all.
I've now seen organisations which undertake serial production of large volumes of a real product implement "Agile Manufacturing" in which the whole development and manufacturing process is iterative, and improvements to the product are constantly integrated throughout production…
This has positives for the manufacturer and the initial buyer, but causes additional complexities downstream especially for service/repair as it creates a myriad of slightly different models which may or may not be documented fully.
I was also witness of (but not party to) a project where the customer was allowed to, in effect, become the design authority – utter disaster!!!
I don't think that's guaranteed to be a disaster, it's down to the person/people involved understanding the role they're taking on and ensuring they meet the requirements the organisation has of that role.
I've acted as both "Principal Designer" on projects where we've put packages of work out to subcontractors whilst the overall project is managed in-house, and "Clients Engineer" on projects where we've let the entire package to an EPC.
The skills are allied but different:
- as a clients engineer, you have to analyse the designs and challenge decisions to get the client what they wanted, but you can't go interfering with the actual design process directly unless you want to cause a huge bureaucratic mess.
- as principal designer, you have to take total responsibility for the design and that means that you must fully understand every aspect, or at the very least how each aspect integrates with every other aspect, and fully bottom out any disconnects with the relevant teams.
If you have someone who is determined to take on the authority and accountability of the latter, but approaches it with the attitude and responsibilities of the former, that's when it should be expected to rapidly devolve into a horrendous mess!