Defining efficiency in IT is harder than defining inefficiency. Inefficiency could for example be defined as when resources/time/effort is wasted in IT functions.
There is nowadays much talk about efficiently aligning IT with business. IT functions should be getting the right things done in an agile manner as requested by the business. There is some merit to this, but mostly its just empty talk. If business have no clue what they want, or if business have no way of communicating what they need you will not either get any efficient aligned IT function for your business.
You must to a large extent know what to do from all stakeholders point of view in a balanced way. Some unfortunately tend to understand that business alignment only mandate implementation of the often arbitrary requested features. Truth is that a successful efficient system must fulfill needs raised by all stakeholders regardless if they are business representatives, technical deployer or help desk support professional. Some requirements are more important than others, but letting one part decide on priorities is not wise.
This does not mean that ALL functional or nonfunctional requirements should be implemented. It is equally important to be able to disregard all not well thought out requirements. Featuritis is a dicease where often business are forced to prematurely state all requirements up front (as done for waterfall projects) to be sure that they don't need to be involved in any cumbersome change management process intended to limit changes more than fulfilling any other need.
So how do you know what to do? One thing you could try is to ask me, but ill just answer that I don't know... The key, if there is any, is to involve everybody in your quest for efficiency. This has been shown to work in factory settings, so it should work in any setting. The people doing the work that will be affected by the change should know what can be done better and where it will lead, but getting the ideas out into the open will take a bit more than just asking for comments in a email message sent to all. An other thing to rely on is experience. If you don't have experience you have a good opportunity to acquire some by trial and error.
An useful guide to efficiency is to keep the spirit of Occam's razor in mind, or try tp do everything as simple as possible, but no more simple. Excessive complexity leads to waste, or aspects that will never be used that will be in the way of further development.
Nature has a couple of important lesson for us to learn. Always start small and evolve from there. Kill of bad ideas often and early, before they become multimillion failures bringing the whole company down. Everything does not need to be perfect, just good enough will do. Interaction with stakeholders and suggestions for small changes should be welcomed at every opportunity. The ability to test out new small features in a cheap way without substantial risk can be one source of efficiency. Doing small nondisruptive changes quickly is why agile movement is pushing. Note however that any agile approach by itself will not guarantee efficiency.
