The truth about introducing intranet portal

    Author: Meldazhis Pavel, Leading Specialist, Corporate Solutions Department, our IT agency.

    A year has passed since the writing and publication of this article, it has not lost a drop of relevance. We share it with the habrasoobshchestvo to refresh the memory of the customer and the contractor. At the end of the month, wait for the continuation. Let us tell you about the briefing process.

    Roots of problems

    This article is the answer to the client's question: “We have approached you, since you are professionals, will you introduce a portal to us?”. More often, we hear this question from the IT-director, who was given a similar task, less often from HR or a marketer.

    The question arises from the fact that the person responsible for the task does not know what to do next. And worse - he does not see the motion vector, does not represent the goal towards which to strive. This is the first problem.

    A puzzled employee is looking for an answer on the side, appeals to companies that have already undergone this procedure. By the way, most often such clients are asked to share the practice of implementations, expecting to get an idea. The client’s steps are clear and correct: if you don’t know yourself, ask someone who knows. This raises the second problem - the agency.

    Intranet portals are typically implemented by web development agencies. Before that, they made websites, then Bitrix had a product called Corporate Portal, and the agencies began to work on them too. They opened specialized departments, since the development of modules on the portal is more complicated than on the website. Then someone succeeded in this, retrained and called himself an integrator. Anyway, the agency is techies: someone cool draws design, someone is a professional in branding, someone in marketing research, someone else is good at coding and knows how to integrate with various systems.

    But, clients forget or do not realize that the agency is not a business coach. He is not faced with the task of “identifying the internal problems of the client and changing the business processes so that the company works like a clock.” The agency can correct them at the time of automation and overlaying into the IT environment, suggest a convenient solution, or even discourage them from automation, but not initiate it.

    Not able and not in the competence of agencies to create mechanisms for the operation of someone else's business, integrators help it to be mobile and useful.

    And when you, as a customer, come to the integrators with a request to do everything correctly and beautifully, or you, as an agency, take up the project of implementing a corporate portal, the question arises - where to go next?

    Two approaches to implementation

    I approach. Repel the functions of the system.

    It looks like this: the agency tells the client about the tools that are in the portal. The client then determines the tools he would like to implement. The agency tells more about all the possibilities, helps in setting up, fine-tuning for the task.

    Pros :

    • Budget - using standard tools.
    • Quickly - for that reason.
    • The system almost does not change, it is easier to update.

    Cons :

    • The client adapts to the system, not the system to the client. The solution is often inconvenient, incomplete. Every business has new features.
    • As a rule, this is automation at the “fan” level, and not a solution to specific customer problems.
    • Most often, these portals are used less and less, and as a result is not used at all. The portal lives on content, there is no content or it is outdated - the portal has died.

    Such an approach is the lot of young agencies. Their goal is to ship the license, not to capitalize on support and development.

    II approach. Repeat from customer problems.

    The client comes to the agency with a problem and, of course, a request to solve it. The agency is immersed in the task, studying it together with the client and looking for ways to adapt existing tools or options for developing a new one. Such a thoughtful, research approach is more correct and effective.

    Pros :

    • The system adapts to the client, and not the client to the system - a point solution.
    • The more you do, the steeper will go, the more the appetites will develop, the more the tool will be in demand and will be of benefit.

    Cons :

    • This is a long time. It takes time to study the task, immersion, coordination, implementation of the plan.
    • It is expensive. Customized solutions and special designs are more expensive than standard portal shipments.
    • Higher risks, if not earn (primarily financial). This is directly related to the developer’s literacy, his honesty and the integrity of the agency. Not all problems can be solved by the portal, of which agencies willing to make money are silently silent.
    • The reality and ease of updating the portal in the future directly depends on the developer’s “straightforwardness”.

    First of all, the choice of approach - the client's decision. If a business is small, internal communication does not imply a multistage and confusion, does not need customization of the portal, then there is no sense in overpaying and processing. Otherwise, when the company has more than 500 employees, and the portal should solve not only time tracking, task setting, corporate notification, but also workflow, with integrated third-party systems - you will not manage out of the box.

    Which option to choose - the client himself decides, not the agency. But you need to understand that the second approach is always a clear goal setting - “why do you need a portal and what problems do you want to solve with its help”. These are the main and difficult questions. The matter is complicated by the lack of information on the capabilities of the system, lack of experience in the application "in its own skin." Until you try it yourself, you won't understand.

    It turns out a vicious circle in order to understand “Why the portal?” - you need to try, to try it - you need to understand “Why is it needed?”. Here, by the way, the cloud version of the portal helps out (for the test, register, install and test the cloud).

    Picture of the world of the integrator

    Similar logic (separation on simpler and more complicated) can be traced in the segmentation of platforms. It turns out a very interesting picture.

    There is a solution on MS SharePoint, these are big hulking systems, expensive to maintain and develop. But it is important that the development of such intranets is based on the needs of the client and its business. Yes, there are solution packages that cover many typical needs (messenger, forum, employee card, structure, photo album), but, as a rule, everything is written “from scratch” for individual client tasks. Every business process is spoken, and automation is implemented. Such solutions ultimately have a longer lifespan and they are considered more efficient implementations. Systems like MSS are chosen by already mature companies that have an understanding of the key tasks - “what is needed from the portal”. It is not difficult to guess - the introduction of MSS is on the II approach.

    In contrast to the MSS portal Bitrix24 is already supplied as a package, without major changes. Bitrix24 has little individuality, it does not always cover the needs of the client. Every business is similar, but each has significant differences. The process of implementing the portal on the B24 in most cases - I approach.

    This begs the question: "Why not apply the II approach in the implementation of Bitrix?". And this is a true thought.

    Over its implementation, we work long and hard. And formed for themselves the general principles of portal implementation. They are written with our sweat and blood: where to start the introduction and what to strive for, what questions to answer. Below are the steps towards a working tool - the ideal of the customer and the agency.

    General recommendations for implementation

    1. Define goals and objectives for implementation

    At least understand where it is bad and what you want to do better. The more specific the goal, the more likely its achievement.

    Successful examples:

    • Automate the process of setting and tracking employees KPI. Now it is implemented in paper form.
    • To instill a culture of setting and performing tasks. By the way, for this and in Bitrix24 everything is already there, but there is no regulation. Development of regulations - the client's task. Familiarize yourself with the functions of the platform - the task of the agency.

    Bad example:

    • Automate the company's internal business processes, for example, ordering a taxi, vacation application, travel application.

    On the one hand, it seems to be concrete, but one problem. The agency may not be puzzled seriously by this wish. The unqualified manager will respond to the customer: “There is already a standard business process for a travel application in Bitrix, you can use it.” The problem will be revealed later, when the client understands that the standard process does not suit him, does not work out the necessary stages of coordination. Revision is too expensive or the agency is in principle incompetent to provide advice. As a result, the client is not satisfied with the result, nothing really works. The agency, having received its share of the license, retires. And it happened because:

    • the client has not set a clear goal;
    • the agency did not ask clarifying questions, respectively, setting a minimum cost;
    • the client chose for the price (it’s strange to pay for the business process when he’s already out of the box);
    • the agency cannot realize what the client wants from the specified budget - it has not been pledged;
    • the client is not satisfied, disappointed both in the agency and in the product.

    Now, if the task is to formulate at least like this: “Automate the process of secondment of an employee that occurs according to the regulations” and make sure that the regulations themselves are attached, then half of the agencies will most likely be eliminated immediately. Because it is a difficult implementation and you need to think.

    2. Mark areas of responsibility

    The customer must clearly understand where the contractor’s area of ​​responsibility ends. The task of the contractor is to convey this to the client so that the false feeling that the responsibility for the implementation of the portal lies only with the agency is not created. Agency - techie, maximum - consultant.

    And the area of ​​responsibility of the customer ends on the technical performance. There is no need to teach the agency how to properly use the standard function or impose the use of the list module in order to save money, this is not always right at a distance (support, updates, improvements), and sometimes it is not at all convenient from the point of view of usability.

    Let me dismiss a myth: the customer thinks that the agency, at every opportunity, is looking for a way to complicate the decision and make more money — this is not so. If the agency has enough work, the specialists are technically literate and have already had experience with similar tasks, then they really offer the best option. Trust them and do not look for a trick.

    3. Find burning eyes

    On the client side there should be a person in charge who “itches”. He wants one, second, third ... He actively uses the portal, and draws his colleagues into the process. It is important that this person has leadership support. Uninterested, not wishing anything extreme - not about good work. If there are no “burning eyes”, then most likely the project will fail.

    4. Set priorities

    Work on the implementation can last forever, there is no limit to perfection. In a living organization there will always be something to automate, so it is important to prioritize between tasks or areas. It is better to work with two threads. For example, electronic applications and refinement of the wiki module. If you work differently, then, firstly, it is difficult for the customer in charge to hold everything in your head. Secondly, the contractor will have to connect new programmers to the project (conflicts are possible “from a technical point of view”). Thirdly, users need to give the result in portions, and not all at once.

    5. Introduce parts

    Up to the fact that first on the portal there is nothing at all.

    Let me explain why:

    • Every tool you need to learn, and then learn to use. Create a usage policy. It takes time and clean space to get acquainted with the functionality and initially not to get lost in the structure.
    • If you immediately dump everything that the portal can on the staff, they will be lost, their eyes will run, they will not learn to use.
    • The probability that some tool will not work or will work crookedly is much higher if all the capabilities of the portal are realized in a crowd. Each stage was not tested separately, the portal was not gradually filled with blocks, no errors were detected - hence the discontent and refusal of the portal.

    6. Test

    First, the pilot group tests the portal, then all the others. It is important that the leadership be among the first. As a rule, HR and IT specialists are allowed into the system, they are accustomed to adapting to new tools.

    7. Give the portal load

    You buy a new phone, and the first few days you experience discomfort. The old was "familiar." But do not go back to the outdated model? You call, write, scroll, use the phone every half hour - you quickly get used to it and eventually you cannot live without it.

    Is this all for what? It is necessary to tie up business processes on the portal and not give way back. The appearance of the resource is not a magic wand, by the wave of which everyone will begin to use the portal and enjoy the results. A good outcome is the work of both parties.

    If something can be done on the portal, then you need to do it on the portal, banning other tools (but it is important that it is convenient and fast!).

    A good example. Announcements and important news to employees are sent by mail. The message is lost, plus there is no operational feedback: who read, who ignored, who did not see. The portal message on behalf of the company arrives all. Comments are left right there. Skipping the recording will not work - the notification will hang (and get on your nerves) until the employee clicks the “familiar” button. Quickly, conveniently, effectively - will work.

    Bad example. Each in their work uses files. As a rule, the company has a network drive, and a colleague can throw the “path” to the file. This is especially suitable for small companies with a single storage system. To oblige the exchange of documents only through the portal is a bad idea. Throw a link to a colleague much faster. On the other hand, through the portal, you can assign access rights restrictions to a specific file, send it “offline”, password protected or limit the link by action time. In this case, the portal is good. For each scenario - its own tools and the task of the agency to talk about the possibilities.

    8. Determine success criteria for implementation.

    I would divide the criteria into two closely related camps.

    The first. The solution of specific problems. Automating the process “travel from application to report”, implementation of the Help-desk, etc. These are clear tasks that are analyzed / designed / implemented / run into trial operation.

    Second. The usefulness of the implementation. It is difficult to measure empirically, it is felt at the level of everyday life of employees. If they refer to the portal as an authoritative source, this is where they are looking for the necessary information - this is the main indicator of the portal’s use. When in the office you can hear phrases like: “I don’t know which version of the regulation / order is the last, look at the portal, it’s definitely fresh there” or “I commented out the file in the task on the portal and attached the file ...”, “I’ve put the idea on the portal filed, vote for her "or" ask everyone a question on the portal, I'm sure someone faced the same problem, "etc. we can assume that the portal has been successfully launched.

    Total that must be remembered for portal implementation:
    1. Clearly formulated goals and objectives.
    2. Who is responsible for what.
    3. Priority, portioning and sequence of tasks.
    4. Test group mainly from the manual.
    5. Mandatory load on the portal, without problems, he "will die."

    Here are the basic principles, following which the output is a working tool. If you are a potential customer and are reading us, then remember - not everything is in the hands of digital agencies. It cannot make a business more profitable without your help. And if you are an agency, then remember - asking the customer for all the necessary information, specify, and talk about areas of responsibility in advance. And of course, follow our recommendations!

    Also popular now: