I previously described software engineering as building effective software systems efficiently. In this description, "effective" means doing what it is intended to do — given what is feasible. The qualification is important. In the 1950s is would be unreasonable to declare a payroll system "ineffective" because it couldn't be accessed by employees to update their details. But a payroll system that gives employees the wrong amount is ineffective in any era.
By "efficiently", I mean using no more time, money, and other resources that we should need to — given our current understanding and support. The qualification again is important. If we were to build the Great Pyramid of Giza again, if it took the same time and cost the same the client would probably be justified in being unhappy, as we know a lot more about engineering and have better techniques and tools for such construction. Similarly, if we were to build a payroll system with the same capability as one from the 1950s, we would expect to to be much cheaper to build — and of almost no value to anyone because our expectations have changed.
The attributes "efficient" and "effective" apply to any form of engineering. What distinguishes software engineering from other forms of engineering is that the "material" used to construct the system is software. When making decisions about software engineering as a discipline (such as designing a curriculum), the fact that constructing software is what it's all about is key. It is not enough that software be somehow involved. So physical devices that are controlled by software do not inherently have anything to do with software engineering, although the development of the controlling software almost certainly does. Software that is used to create other things (such as computer-aided design systems) is not software engineering. These days, software is nothing special — it is almost impossible to avoid software (software was used so that you could read this for example).
So when are we really in the realm of software engineering? Take databases for example. A discussion about the relational theory the underpins relationship databases, is clearly nothing to do with developing software. Knowing SQL and understanding normal forms can be helpful for building good software systems, but these are basic skills in the same way that calculus is a basic skill for many other forms of engineering. Administering an Oracle database is not constructing software. But understanding enough about the pros and cons of a relational database versus an NoSQL database to determine which is going to provide a more effective and/or efficient software systems is most definitely software engineering.
It's the same for other topics, algorithms, compilers, graphics, networks, artificial intelligence, even numerical analysis — there is a continuum from the purely computational aspects through to the practical use of the topics in software to be delivered to a client. I don't think it is important where the line gets drawn. I can see value in a software engineering programme that includes courses that focus on algorithmic theory, and a computer science programme that includes a course that focuses on building the software for that deals with networks. But if the goal is building a good software system on time and on budget then it's a software engineering programme.