ITIL 4 arrives as a large book of practices, and the instinct of a newly appointed IT manager is to implement all of it, because that is what the certification implied was correct. Six months later most of the documentation is unused, the process nobody asked for is being worked around, and the framework has acquired a reputation inside the company as bureaucracy rather than discipline.
The version that survives is narrower. Start with incident management and request fulfilment, because they touch every user every day and the improvement is immediately visible. Add change management once incidents are under control, because uncontrolled change is usually what is causing half the incidents in the first place. Everything else — capacity management, service level management as a formal discipline, continual improvement as a named practice — can wait until the team has the headcount to own it properly rather than as an unpaid addition to someone's day job.
The specific mistake Indian mid-market teams make is copying process documents from a template rather than designing for their own ticket volume. A five-person IT team receiving forty tickets a week does not need the same change advisory structure as a five-hundred-person IT organisation, and forcing the same paperwork onto both produces resentment in the small team and inadequate control in the large one.
What is worth taking from ITIL 4 regardless of scale is the underlying idea of a service value chain — that IT exists to deliver value to a specific set of stakeholders, and every process should be traceable back to that. Used as a lens for deciding what to build next, rather than as a certification to acquire, it earns its place. Used as a checklist to implement completely, it becomes the very bureaucracy it was meant to prevent.
