July 2010, internship at ESSEC. I was asked to write a report on the innovation process in the group's information systems. I found this text in my emails in 2026, thanks to Claude and the Gmail connector. It is published as is, with minor corrections. Originally written in French.
The report
I will try to summarise in this text my perspective on the innovation process in information systems at EEE.
My experience with EEE began in November 2009, but it was from my integration as an intern in April 2010 that I was truly able to form an opinion on the processes, the actors and the nature of the institution's information system. It was from that date that I could converse with many people involved in its operation, its use and its administration. This view, although partial (I was not an intern in the IS department) and biased (observation was not part of my internship objectives), nonetheless allowed me to form an impression.
A first observation: the user's view of ESSEC's information system, and EEE's in particular, reveals that there is no intranet to speak of, but rather an accumulation of solutions that are not necessarily complementary. Institutional websites, Google Sites, Myessec, email accounts, shared computers, Wi-Fi, the library portal, Banner...
It would be amusing to ask the actors of the information system — students, professors and administrative assistants — to draw a diagram of ESSEC's IT system. The results would be surprising... The confusion experienced by users is amplified by the lack of coherence and usability of the interfaces: a fundamental rule is not respected — users should not need to know how things work to make them work, yet to use them one must understand why they work.
This leads to a second observation: there is no transparency whatsoever on the efficiency of the systems in place. Usage rates, user satisfaction, potential time savings, energy savings, telephony savings, paper savings, revenue gains, improvement of the school's visibility — all swept under the rug. There are no performance indicators and no visibility on return on investment.
This transparency also does not exist for the functioning of the IS department itself. The prevailing rule appears to be concealment: how does a project progress day by day? What are the criteria that make one project more important than another? The situation could be compared to a contractor who would not let the owners and future inhabitants of their house follow the progress of its design and construction.
As I see it, the process for launching a project is roughly the following: a system actor requests an improvement, the IS department, without genuine consultation, assesses whether the request is worthwhile, prioritises user needs according to an opaque process, defines the scope of action alone, implements a solution, and whatever happens, happens. If the actor is not satisfied, their only recourse is to not use the solution and to lose all credibility for any future request.
Indeed, contact with the end user is nonexistent. From what I understand, the educational engineers are supposed to provide the link, but there is no report, no qualitative or quantitative method to have a written record of this connection.
I am also surprised that the IS department has no expertise in project management. Its role is limited to maintenance, technology watch and feasibility studies. The creation of practical or innovative solutions does not seem to be part of its remit, nor even development.
The only executive in the IS department — that is, a person capable of giving direction to projects — is Jean-Pierre Choulet, and it seems impossible to me that he could follow all projects simultaneously. This is probably why the dogma of "no development" and the search for turnkey solutions was established. As if the ESSEC group had no specific needs. So they are forced to cobble together shaky solutions with no sustainability.
A problem that would not be one if finances were unlimited: yet everyone complains about the lack of resources. This leads us to the next observation: poor management in resource allocation.
It would be interesting to know what human resources are mobilised solely for the operation of information systems. The number of educational engineers hired to compensate for the lack of involvement of the legitimate actors — professors and programme assistants — seems disproportionate to me and adds to the confusion.
By hiring people to do work that teachers do not want to provide, we legitimise a situation in which the design and publication of digital content is not and will never be the responsibility of those who have the pedagogical legitimacy to do it. The hiring solution is systematic and self-perpetuating, as Parkinson describes for civil servants:
1. "An official wants to multiply subordinates, not rivals": there is a natural tendency to recruit someone more competent than oneself in at least one area, but also to divide work to avoid being challenged by a collaborator. This creates needs for internal coordination, which leads to additional workload, then the hiring of additional staff. An "autarkic" system is thus built that will consume, endogenously, a growing share of available energy, leading to the second law.
2. "Officials make work for each other." The more officials there are, the more the requests for approval they send to each other, or comparable tasks, keep them busy, so that the work accomplished from an external perspective by the administration as a whole does not increase.
It seems to me that this Kafkaesque situation is due to the absence of any leverage by the business over information systems: the IS department holds technical, decisional and financial power. The IS department does what it wants, how it wants, with the means it wants. Paradoxically, its members constantly complain about the lack of involvement from business people, the lack of resources, and are satisfied with all their reflections. Self-criticism does not exist.
Beyond the organisational questions and returning to the first observation about user perception of the IT system, there are also questions of principles and definition of the role of information system actors at ESSEC and the IS department.
Within the framework of CPI discussions, I had proposed a few principles for a good information system: unity, universality, utility, usability. To which we add humanity. Unity means both the coherence of the system, the interoperability of its components and a simple mental model of the system for the user. Universality means the proper functioning of resources with all user devices but also taking into account all needs that support training objectives — knowledge, technical know-how and behavioural skills. Utility is both the benefit derived from implementing a new feature and its actual use: what is not used enough should be removed. Usability is the principle that dictates not offering a function if one has not thought of a use within the user's reach. We add humanity, meaning a system at the service of the user and not at the service of itself, but also no dehumanisation of resources: someone does something for someone else through the system; nothing should be done for the system.
Within usability we find ergonomics. It seems obvious to me that nobody takes care of interface usability when we see the self-satisfaction at implementing a solution as unfriendly as Banner.
The IS department's only stated ambition is dematerialisation, without ever defining its scope or even the term itself. We witness an appropriation of free content provided by other institutions that very rarely leads to a dematerialisation of EEE's own content. Video seems to be the only existing means to do so, without ever questioning its effectiveness — "others do it so we should too."
The ESSEC group's IS department operates in a follower logic — and a poor follower at that — not a leader, which is the exact opposite of what it is supposed to embody.
Another striking fact: there is no business intelligence, or if there is, it is not visible. No help for scheduling appointments, no room booking... Moreover, there is no link between content. For example, between a professor's name, their biography, their publications, their email address, their schedule, their phone number, their assistant's name, their courses... So much information to be found in different places. Or regarding IT support: the operating principle is as follows — if support has resolved a problem then there is no problem, without questioning the causes of a problem so that it does not recur...
In my view, the real problem lies in the absence of user leverage over the IS department and the confusion between several departments.
Users are the clients and the IS department is in a monopoly position. The role of the IS department is to create natural links between actors, to facilitate the transmission of information and to support processes through ICT. The IS department has forgotten that it is not at the service of computing — like the PTT technician was responsible for the proper functioning of telephone lines — but that it is at the service of the ESSEC group by creating links between those who know and those who want to know. The argument always put forward is the lack of involvement of professors and students in using IT. It is not by offering training that costs in manpower, time and money that the problem will be solved, but by offering solutions that these reluctant users will be able to use naturally because it is more practical than doing things the old way.
Furthermore, I still do not understand why content and flows are mixed. In my view, the IS department should handle information flows, and other departments should handle content. Educational engineers belong to the second category. Listening to them and observing them, one would think they work for the IS department. In my opinion, administrative assistants are far more useful and effective than educational engineers in promoting student satisfaction and learning. A priority for the IS department should be to improve IT interfaces for assistants rather than showing off in front of students. I estimate that assessments account for 20% of assistants' time, when that percentage should tend towards zero. If we add room booking, schedule management and time lost answering questions whose answers could easily be accessible on an effective intranet, we would free up many resources to allocate far more wisely.
To conclude, I would add that the IS department should be much more in contact with students and faculty. There is certainly no link between this department at the heart of the ESSEC group and professors of innovation, management, strategy, or even information systems.
In summary: performance indicators, operating principles, links between system actors, a strategy that makes sense for the group, and a substantial ongoing self-criticism are all missing and should nevertheless be at the foundation of the innovation and improvement process in the group's IS and EEE in particular.