ERP for the university: problems of choice and implementation
Sooner or later, every educational institution (OU) is faced with the task of automating certain processes occurring in it, and besides, there are now more than a dozen erp-solutions that have in their arsenal mechanisms for automating business processes education. In the article I will try to talk about the pitfalls that can occur at the stages of choosing a system, as well as implementation and use. On Habré there are not one hundred articles on erp, but in the context of the introduction of the system in the university, I have not found one. The information given in the article is based on the author’s personal experience in introducing an erp-system in a state institution of higher professional education.
As soon as the management matures to the start of “automation” of one and all, the first question arises - the choice of a suitable price / quality / requirements for a turnkey solution or writing your own software:
So, let's begin ... If there are no clear and understandable business processes in your OS (and getting an education is also a kind of business process), then you have nothing to automate by and large, there is no sense in erp at the university, in the case where transparency processes are not needed by anyone (including the manual), and today it (transparency) is similar to a turbulent river during the flood period — in turbid water, the introduction of an erp system will be nothing more than an annoying fly that only prevents your swamp from being even and unshakable. By muddy water, I mean endlessly changing curricula (sometimes even several times during the school year), playing in the dormitories, juggling budget and paid places, artificial scientific achievements of staff members, hiding recovery mechanisms and so on, it’s not for me to teach you. If you have everything somehow, then you don’t need any erp-system in the university, live better without it, because it’s better that you don’t get the desired effect anyway.
')
Imagine a situation that the management nevertheless decided to introduce a certain system and instructs someone to reconnoiter about the cost of finished products.
It is very important to make a team of those who will conduct a search system. Often, this responsibility in universities is imposed on the IT department (well, of course, it’s all about the computer) and they are cruelly wrong, because The end user of the system is not a university IT specialist, but a manual, dean's offices, an educational unit, office, departments, and maybe students. Therefore, at this stage it is extremely important to determine what all these listed categories want from the ERP system; it is necessary to understand its practical significance in daily work, to see the need for automating certain routine processes. Ideally, it is necessary at this stage to select and approve (by order or decree) the list of persons participating in the implementation of a product that has not yet been selected, paradoxical as it may sound, and the person responsible for the implementation must be a person whose capabilities include issuing orders for those units, automation of whose processes is assumed.
Obviously, the introduction of the system is necessary at a minimum to receive certain reports (that is, operational information), and ideally to increase the openness and transparency of the processes occurring at the university, to obtain a tool for making strategic decisions by management, which ultimately will affect the increase in the productivity of units, reduce the number of errors in work, etc. Unfortunately, in an ordinary institution of higher education, they are trying to introduce the system sometimes only to get some mandatory reports to the Ministry of Defense ... that's all. ERP-systems sales managers are well aware of this and they are trying to throw dust in the eyes of a potential buyer, stunning him with incredible amounts of ready-made sample reports - “about 100”, “up to 500”, “more than 1000” ... You shouldn’t be carried on this bait, because It is obvious that the word “typical” in the titles of all reports should tell you that they still definitely have to be “finished”. Now, remember the composition of the IT department of the humanities university ... In a good system, the user must independently generate all the reports he needs, and not run for it to the IT department with round eyes. The system should have an intuitive “designer” of reports with the obligatory export of everything selected in Excel. We all know well how often letters come in from above, in which it is necessary “yesterday” to submit this or that information to the ministry, and now imagine that among the “more than 1000 standard reports” of the 1001st report is not provided. What are you going to do? Even if you immediately order the production of the required report from the manufacturer of the system, it will take 3-4 days to produce and test it. If there is a universal tool in the system for retrieving the necessary data, the user will make this report himself in 20 minutes. Do not fall for the manufacturer's phrases, such as “with minimal knowledge of SQL, any report can be created in 30 minutes” - in this case, they conceal you, besides “minimal knowledge of SQL” you also need to study the database structure (300 sheets). some FastReport, for example, and this is not a user level! Remember, when buying a TV, do you get a soldering iron in the store (just in case)? Not? So why then to the ERP-system to put in the package also a programmer?
In any state institution of higher education, when choosing, the cost of software is mistakenly set, and its developers are well aware of this, so they are trying in every way to hide the real amount that OU will have to pay for the purchase and implementation of the system. The policy of possessing non-exclusive software rights should be transparent and understandable to the buyer, always carefully read the prices, commercial offers, look for asterisks, footnotes and 6th font. Some manufacturers try to keep silent the purchase of the DBMS, some beautifully keep back on limiting connections to the database, keep this in mind. Others are trying to present as many modules of the system as possible, covering, in their opinion, all business processes in the OU. You should not trust the last indicator, because in the university you are unlikely to implement all the modules at once, especially accounting, most likely already works on 1C, and this, too, after all erp, and with it you will have to integrate the new purchase, besides Do not forget that you still want to automate in the first place - the movement of a contingent of students and everything connected with it or the process of negotiating contracts with suppliers. Undoubtedly - the coordination of contracts is an important section of the work of any organization, but do not forget about the main task of your university - this is student training. And besides, if you successfully implement erp at the level of the contingent of students, no one will forbid you to engage in the implementation of any additional functionality. One way or another, priorities must be set correctly.
When choosing a system, be sure to request a demo access to it, and not just to click through the colorful windows, but to try to reflect one or more business processes in the system, for example, to evaluate the convenience of running a receiving campaign and the system’s compliance with the rules for receiving, creating study groups, transfer of a student from full-time to correspondence, registration of a specific order, an extract from it, a monthly required report, etc. Ask Rosobrnadzor for test access to packet data in the FIS Examination and Reception and try to connect your system with it (if you want to save yourself from the routine input of 10,000 applicants through the web). Do not hesitate to ask for the extension of the demo period, if it is limited by the supplier, it is in your interest. If at this stage you encounter problems that seem insurmountable to you and you don’t find an obvious solution in the instructions, it’s not shameful to ask a potential seller to show you how this problem can be solved and solved right now online. Do not buy into excuses like “this is a demo version, everything works like a clock in a real system” or “at the moment this functionality is not implemented, but by the time of purchase we will fix everything”, “it is already in the plans”, “we have this a hundred times implemented ”,“ it's easy to add / configure ”! Believe and remember - what you didn’t see now is likely to never be realized (well, except for your money), just feel free to put a minus on this item, because until you signed the contract for the purchase of this particular software - you order music you and no one else.
Try to involve as many units as possible in your work with the demo version, whose work you want to reflect in this erp-system. Pay special attention to the program interface, if it seems overloaded to you - know that the implementation process will be delayed, because ordinary dispatchers of deans offices, laboratory assistants of departments, employees of the training department will work with the system. From a practical point of view, evaluate the feasibility of the approach proposed in the system for creating records and filters. Remember that the system should be first of all friendly to the user, he should want to work in it, forgetting about MS Word, as a single database for him for all occasions.
Collect and analyze all forms of documents (orders, admissions, statements, extracts, reports, etc.) taken at your university, classify them and try to find a way to implement them in the system. If you experience difficulties, ask the manufacturer to help you. Immediately specify the cost of implementing the missing functionality. Find out if the system is compatible with the GosInsp curriculum file formats, ask the developer to demonstrate the process of importing your plan into the system. Remember that the MMIS Laboratory often changes the format of the plan files and their structure, find out if your potential erp is ready for this. Ask about the extent to which the program implements support for the GEF of the 3rd generation.
If the ERP system is a client-server application, ask how the client application update process is implemented. If during the system upgrade you have to send a slider from the IT department to reinstall applications from all users, think about the advisability of buying this software a hundred times. Perhaps at the initial stage you wish to limit the automation of business processes of the university management staff and the update will not be a global problem, but what if the system covers all the departments? .. And if there are 100 departments at the university? And if you decide to involve students in the system? .. Find out if the system interacts with AD.
At the stage of choosing a system, pay special attention to the documentation, and both on the technical (configuration and administration), and on the user. All system functionality should be described in detail in manas. You should not seriously take a product whose system version described in the user manual does not match in the current software version. Do not be fooled by the documentation, which reflects only the colorful screen-interfaces of the program, and their descriptions contain something like the following: “when you click on the delete student button, the student is deleted”. If you see a manufacturer with a similar approach to user instructions - prepare money for endless training, training, seminars / webinars, consultations, and more. Do not believe in promises, such as “right now we are preparing a new version of the user's manual” - believe me - no one is preparing anything “right now”. If there are no clear manas, it means that someone needs it ...
Do not be fooled by the open or partially open code of the system, remember, all erp-systems write teams of programmers. It is unlikely that a full-time programmer at your university will be able to complete the system for your needs, without making mistakes (not from its illiteracy, but from a lack of understanding of the logic of the application, its modules). Fix it later will be very difficult, and sometimes impossible, and everything will have to start from scratch. And besides, when upgrading the system with a high probability, all your doping will disappear at best, and at worst, they will completely paralyze the system, plus you will lose the software warranty. If you really want so that your OU could sign something in the system by itself - look for erp with the support of client extensions, this is the only correct option in your case.
If you are inclined to a particular erp-system, be sure to check with the manufacturer about the experience you have in implementing this system in universities of your own profile. Yes, yes, it is the profile, because Many processes considered obvious at a medical university will be completely unnecessary in the conservatory, for example. If this system has not been implemented yet in any higher educational institution of your profile, and it has been implemented only at colleges of the same direction - wait for trouble, since The educational process in high school and university are different things. Do not hesitate to ask the names of those OU, where the manufacturer has already sold (or has already implemented) its product. Feel free to call these universities and ask about the effects of implementation, let your colleagues share their experience in operating the system, ask them to evaluate the convenience of its everyday use, you will not be denied. In case of unsuccessful implementation, ask why the system “lies” or is used by 10%, which was the reason - the developer may have let you down, it is possible that the system did not prove to be very user-friendly or did not meet the expectations of the university management or the end users caused the failure. and their low level of computer literacy. In this way, you will get the most objective description of the system.
In general - at the stage of searching for an erp-system for a university, you should not put money in the first place, focus on the points described above and you, without knowing it, will save a lot on the implementation process.
So, the choice is made, the bills are paid, you have in your hands the distribution kit of the ERP system purchased and you are going to put the software on the server with a glow in your eyes. A couple of clicks <Next> and the system you have installed. What's next? And then the most difficult and time-consuming stage begins - implementation ... From this day, the management will wait daily for the results, and you, as an implementer from the university, will get to play every day for delaying the process. The first myth that should be dispelled in the head of the university management, and the sooner the better - “The ERP system we buy is ready to work immediately after installation on the university server”. Far from it. More precisely - this is generally not the case, in principle. Any ready-made solution is a designer with some reserve of possibilities and this designer does not work out of the box, he will not print all the forms you need, do not fill the students' base on their own, do not load from outside the curriculum. Properly implement these capabilities - and there is a properly built implementation process.
When buying a system it is important to decide how (and most importantly - at whose expense) the implementation process will take place. There are only two options:
What can I say ... we went on the free path and for two years did not really implement anything. No, of course something works, we use something, but in general, it’s not clear to everyone why it was necessary to make a garden, since even without it you can live. I myself would not call what works for us - erp-system.
Let us return to the order (order) on the list of persons responsible for implementing the system, about which I wrote above. We did not have such a list to this day. As a result, all the stones fly only in one garden - in mine (and I'm just an employee of the IT-department). As already mentioned, any erp-system requires configuration for a particular university for business processes, sometimes it is impossible to achieve what you want by simply switching checkboxes in the admin panel, it is often necessary to make certain changes to the system, in short, developers need to finish it.
It is important to remember that the introduction of any information system requires the participation of not only technical specialists. Without the active participation of users, management organizations and developers, it is often simply impossible to implement it. At the implementation stage, you will encounter the fact that most of the employees even in one university department are used to doing the same work in different ways, that many business processes overlap, duplicate or even exclude each other, that the work of many departments is absolutely unregulated there are no uniform standards for numbering documents and so on. Actually, this is why information and automation are so important, because make all processes completely transparent. This is because any information system is a tightly regulated and designed data structure, which implies clear and obvious work procedures, eliminating any chaos. But someone likes to work in chaos, someone is profitable, someone just got used and does not want to change anything. Such people are in any organization and they will in every way impede the implementation of an information system. Yes, you will have to deal with sabotage, the real sabotage, first of all, from those university staff who were not very friendly with the computer even before the introduction of the system, and now even more so. The unification of all documents in the university will be a blow to the mossy antiquity and conservatism: some will have to be excluded, others will be reworked, generalized, you may even have to change the usual numbering of the records, and so on. Most likely, at the beginning of the implementation stage, users will have to keep documentation in the erp-system and using the usual MS Word and Excel, which undoubtedly will not cause either applause or applause in any department of the university. This will have to accept. And that is precisely why the most remarkable document (order or order) will be needed, which will regulate the responsibility of specific individuals in the divisions for the implementation of the system. “- ” . , . - , , . , , . 30- , . , , - - , — , ( ), , , , .. 1 , , …
, , 2 2- , , 18:00 , 20- , 5- , , , “”… , , erp- ,
As soon as the management matures to the start of “automation” of one and all, the first question arises - the choice of a suitable price / quality / requirements for a turnkey solution or writing your own software:
- Writing your own erp is not an easy task, which technical universities, forging personnel can also solve for themselves, too, however, when deciding to write their product, management later faces such a trivial situation as staff turnover, as a result which the new programmer, at times, cannot understand the code of the previous one and starts rewriting some parts from scratch, which pulls the tangle of problems. In fact, it turns out that samopisnye systems are developed “on the knee” and, as a rule, without documentation, besides, it is difficult, time consuming and expensive to develop seriously, if you compare the development time, the cost of maintaining specialists and all overhead costs, it becomes Obviously, it is easier, cheaper and faster to take a good finished product and customize it. Especially if this product has already been tested in other OU.
- For deeply humanitarian universities, writing your own software product is an unrealizable dream due to the fact that the IT department is most often represented by the chief and two or three “runners” who take the jammed paper out of the printers in the accounting department and periodically reinstall the OS, everything else is outsourced.
So, let's begin ... If there are no clear and understandable business processes in your OS (and getting an education is also a kind of business process), then you have nothing to automate by and large, there is no sense in erp at the university, in the case where transparency processes are not needed by anyone (including the manual), and today it (transparency) is similar to a turbulent river during the flood period — in turbid water, the introduction of an erp system will be nothing more than an annoying fly that only prevents your swamp from being even and unshakable. By muddy water, I mean endlessly changing curricula (sometimes even several times during the school year), playing in the dormitories, juggling budget and paid places, artificial scientific achievements of staff members, hiding recovery mechanisms and so on, it’s not for me to teach you. If you have everything somehow, then you don’t need any erp-system in the university, live better without it, because it’s better that you don’t get the desired effect anyway.
')
Imagine a situation that the management nevertheless decided to introduce a certain system and instructs someone to reconnoiter about the cost of finished products.
It is very important to make a team of those who will conduct a search system. Often, this responsibility in universities is imposed on the IT department (well, of course, it’s all about the computer) and they are cruelly wrong, because The end user of the system is not a university IT specialist, but a manual, dean's offices, an educational unit, office, departments, and maybe students. Therefore, at this stage it is extremely important to determine what all these listed categories want from the ERP system; it is necessary to understand its practical significance in daily work, to see the need for automating certain routine processes. Ideally, it is necessary at this stage to select and approve (by order or decree) the list of persons participating in the implementation of a product that has not yet been selected, paradoxical as it may sound, and the person responsible for the implementation must be a person whose capabilities include issuing orders for those units, automation of whose processes is assumed.
Obviously, the introduction of the system is necessary at a minimum to receive certain reports (that is, operational information), and ideally to increase the openness and transparency of the processes occurring at the university, to obtain a tool for making strategic decisions by management, which ultimately will affect the increase in the productivity of units, reduce the number of errors in work, etc. Unfortunately, in an ordinary institution of higher education, they are trying to introduce the system sometimes only to get some mandatory reports to the Ministry of Defense ... that's all. ERP-systems sales managers are well aware of this and they are trying to throw dust in the eyes of a potential buyer, stunning him with incredible amounts of ready-made sample reports - “about 100”, “up to 500”, “more than 1000” ... You shouldn’t be carried on this bait, because It is obvious that the word “typical” in the titles of all reports should tell you that they still definitely have to be “finished”. Now, remember the composition of the IT department of the humanities university ... In a good system, the user must independently generate all the reports he needs, and not run for it to the IT department with round eyes. The system should have an intuitive “designer” of reports with the obligatory export of everything selected in Excel. We all know well how often letters come in from above, in which it is necessary “yesterday” to submit this or that information to the ministry, and now imagine that among the “more than 1000 standard reports” of the 1001st report is not provided. What are you going to do? Even if you immediately order the production of the required report from the manufacturer of the system, it will take 3-4 days to produce and test it. If there is a universal tool in the system for retrieving the necessary data, the user will make this report himself in 20 minutes. Do not fall for the manufacturer's phrases, such as “with minimal knowledge of SQL, any report can be created in 30 minutes” - in this case, they conceal you, besides “minimal knowledge of SQL” you also need to study the database structure (300 sheets). some FastReport, for example, and this is not a user level! Remember, when buying a TV, do you get a soldering iron in the store (just in case)? Not? So why then to the ERP-system to put in the package also a programmer?
In any state institution of higher education, when choosing, the cost of software is mistakenly set, and its developers are well aware of this, so they are trying in every way to hide the real amount that OU will have to pay for the purchase and implementation of the system. The policy of possessing non-exclusive software rights should be transparent and understandable to the buyer, always carefully read the prices, commercial offers, look for asterisks, footnotes and 6th font. Some manufacturers try to keep silent the purchase of the DBMS, some beautifully keep back on limiting connections to the database, keep this in mind. Others are trying to present as many modules of the system as possible, covering, in their opinion, all business processes in the OU. You should not trust the last indicator, because in the university you are unlikely to implement all the modules at once, especially accounting, most likely already works on 1C, and this, too, after all erp, and with it you will have to integrate the new purchase, besides Do not forget that you still want to automate in the first place - the movement of a contingent of students and everything connected with it or the process of negotiating contracts with suppliers. Undoubtedly - the coordination of contracts is an important section of the work of any organization, but do not forget about the main task of your university - this is student training. And besides, if you successfully implement erp at the level of the contingent of students, no one will forbid you to engage in the implementation of any additional functionality. One way or another, priorities must be set correctly.
When choosing a system, be sure to request a demo access to it, and not just to click through the colorful windows, but to try to reflect one or more business processes in the system, for example, to evaluate the convenience of running a receiving campaign and the system’s compliance with the rules for receiving, creating study groups, transfer of a student from full-time to correspondence, registration of a specific order, an extract from it, a monthly required report, etc. Ask Rosobrnadzor for test access to packet data in the FIS Examination and Reception and try to connect your system with it (if you want to save yourself from the routine input of 10,000 applicants through the web). Do not hesitate to ask for the extension of the demo period, if it is limited by the supplier, it is in your interest. If at this stage you encounter problems that seem insurmountable to you and you don’t find an obvious solution in the instructions, it’s not shameful to ask a potential seller to show you how this problem can be solved and solved right now online. Do not buy into excuses like “this is a demo version, everything works like a clock in a real system” or “at the moment this functionality is not implemented, but by the time of purchase we will fix everything”, “it is already in the plans”, “we have this a hundred times implemented ”,“ it's easy to add / configure ”! Believe and remember - what you didn’t see now is likely to never be realized (well, except for your money), just feel free to put a minus on this item, because until you signed the contract for the purchase of this particular software - you order music you and no one else.
Try to involve as many units as possible in your work with the demo version, whose work you want to reflect in this erp-system. Pay special attention to the program interface, if it seems overloaded to you - know that the implementation process will be delayed, because ordinary dispatchers of deans offices, laboratory assistants of departments, employees of the training department will work with the system. From a practical point of view, evaluate the feasibility of the approach proposed in the system for creating records and filters. Remember that the system should be first of all friendly to the user, he should want to work in it, forgetting about MS Word, as a single database for him for all occasions.
Collect and analyze all forms of documents (orders, admissions, statements, extracts, reports, etc.) taken at your university, classify them and try to find a way to implement them in the system. If you experience difficulties, ask the manufacturer to help you. Immediately specify the cost of implementing the missing functionality. Find out if the system is compatible with the GosInsp curriculum file formats, ask the developer to demonstrate the process of importing your plan into the system. Remember that the MMIS Laboratory often changes the format of the plan files and their structure, find out if your potential erp is ready for this. Ask about the extent to which the program implements support for the GEF of the 3rd generation.
If the ERP system is a client-server application, ask how the client application update process is implemented. If during the system upgrade you have to send a slider from the IT department to reinstall applications from all users, think about the advisability of buying this software a hundred times. Perhaps at the initial stage you wish to limit the automation of business processes of the university management staff and the update will not be a global problem, but what if the system covers all the departments? .. And if there are 100 departments at the university? And if you decide to involve students in the system? .. Find out if the system interacts with AD.
At the stage of choosing a system, pay special attention to the documentation, and both on the technical (configuration and administration), and on the user. All system functionality should be described in detail in manas. You should not seriously take a product whose system version described in the user manual does not match in the current software version. Do not be fooled by the documentation, which reflects only the colorful screen-interfaces of the program, and their descriptions contain something like the following: “when you click on the delete student button, the student is deleted”. If you see a manufacturer with a similar approach to user instructions - prepare money for endless training, training, seminars / webinars, consultations, and more. Do not believe in promises, such as “right now we are preparing a new version of the user's manual” - believe me - no one is preparing anything “right now”. If there are no clear manas, it means that someone needs it ...
Do not be fooled by the open or partially open code of the system, remember, all erp-systems write teams of programmers. It is unlikely that a full-time programmer at your university will be able to complete the system for your needs, without making mistakes (not from its illiteracy, but from a lack of understanding of the logic of the application, its modules). Fix it later will be very difficult, and sometimes impossible, and everything will have to start from scratch. And besides, when upgrading the system with a high probability, all your doping will disappear at best, and at worst, they will completely paralyze the system, plus you will lose the software warranty. If you really want so that your OU could sign something in the system by itself - look for erp with the support of client extensions, this is the only correct option in your case.
If you are inclined to a particular erp-system, be sure to check with the manufacturer about the experience you have in implementing this system in universities of your own profile. Yes, yes, it is the profile, because Many processes considered obvious at a medical university will be completely unnecessary in the conservatory, for example. If this system has not been implemented yet in any higher educational institution of your profile, and it has been implemented only at colleges of the same direction - wait for trouble, since The educational process in high school and university are different things. Do not hesitate to ask the names of those OU, where the manufacturer has already sold (or has already implemented) its product. Feel free to call these universities and ask about the effects of implementation, let your colleagues share their experience in operating the system, ask them to evaluate the convenience of its everyday use, you will not be denied. In case of unsuccessful implementation, ask why the system “lies” or is used by 10%, which was the reason - the developer may have let you down, it is possible that the system did not prove to be very user-friendly or did not meet the expectations of the university management or the end users caused the failure. and their low level of computer literacy. In this way, you will get the most objective description of the system.
In general - at the stage of searching for an erp-system for a university, you should not put money in the first place, focus on the points described above and you, without knowing it, will save a lot on the implementation process.
So, the choice is made, the bills are paid, you have in your hands the distribution kit of the ERP system purchased and you are going to put the software on the server with a glow in your eyes. A couple of clicks <Next> and the system you have installed. What's next? And then the most difficult and time-consuming stage begins - implementation ... From this day, the management will wait daily for the results, and you, as an implementer from the university, will get to play every day for delaying the process. The first myth that should be dispelled in the head of the university management, and the sooner the better - “The ERP system we buy is ready to work immediately after installation on the university server”. Far from it. More precisely - this is generally not the case, in principle. Any ready-made solution is a designer with some reserve of possibilities and this designer does not work out of the box, he will not print all the forms you need, do not fill the students' base on their own, do not load from outside the curriculum. Properly implement these capabilities - and there is a properly built implementation process.
When buying a system it is important to decide how (and most importantly - at whose expense) the implementation process will take place. There are only two options:
- the first (free) - the university independently implements the product, in consultation with the system developer,
- the second (expensive) - the developer provides the university with paid services for the implementation of the system.
What can I say ... we went on the free path and for two years did not really implement anything. No, of course something works, we use something, but in general, it’s not clear to everyone why it was necessary to make a garden, since even without it you can live. I myself would not call what works for us - erp-system.
Let us return to the order (order) on the list of persons responsible for implementing the system, about which I wrote above. We did not have such a list to this day. As a result, all the stones fly only in one garden - in mine (and I'm just an employee of the IT-department). As already mentioned, any erp-system requires configuration for a particular university for business processes, sometimes it is impossible to achieve what you want by simply switching checkboxes in the admin panel, it is often necessary to make certain changes to the system, in short, developers need to finish it.
It is important to remember that the introduction of any information system requires the participation of not only technical specialists. Without the active participation of users, management organizations and developers, it is often simply impossible to implement it. At the implementation stage, you will encounter the fact that most of the employees even in one university department are used to doing the same work in different ways, that many business processes overlap, duplicate or even exclude each other, that the work of many departments is absolutely unregulated there are no uniform standards for numbering documents and so on. Actually, this is why information and automation are so important, because make all processes completely transparent. This is because any information system is a tightly regulated and designed data structure, which implies clear and obvious work procedures, eliminating any chaos. But someone likes to work in chaos, someone is profitable, someone just got used and does not want to change anything. Such people are in any organization and they will in every way impede the implementation of an information system. Yes, you will have to deal with sabotage, the real sabotage, first of all, from those university staff who were not very friendly with the computer even before the introduction of the system, and now even more so. The unification of all documents in the university will be a blow to the mossy antiquity and conservatism: some will have to be excluded, others will be reworked, generalized, you may even have to change the usual numbering of the records, and so on. Most likely, at the beginning of the implementation stage, users will have to keep documentation in the erp-system and using the usual MS Word and Excel, which undoubtedly will not cause either applause or applause in any department of the university. This will have to accept. And that is precisely why the most remarkable document (order or order) will be needed, which will regulate the responsibility of specific individuals in the divisions for the implementation of the system. “- ” . , . - , , . , , . 30- , . , , - - , — , ( ), , , , .. 1 , , …
, , 2 2- , , 18:00 , 20- , 5- , , , “”… , , erp- ,
Source: https://habr.com/ru/post/200892/
All Articles