Terms of reference for the modernization of ventilation in research institutes. An example of technical specifications and technical specifications for minor revision Options for penalties

I often attach page prototypes so that the client understands how his site will look like. Then I compose a separate task for the layout designer - with technical details and explanations that will help in his work.

The more complex the task, the more detailed the TOR should be. When I participated in large projects, I saw terms of reference and 30 pages.

Guram Sipki, founder of digital studio Udix Media

First of all, the client needs TK - so that he understands what his site will be like and what the money is spent on. If something is done wrong, he can refer to the TK and ask to redo it.

The TOR is compiled by the project manager after communicating with the client and discussing the task with the designer.

Large customers often ask for very detailed specifications, which describe each button. Small companies, on the contrary, do not like meticulous 100-page documents.

An example of a technical task for finalizing a site

General information

Name of the automated system

"AS SALES"

Customer

Executor

Basis for work

Scheduled dates for the start and completion of work on the creation of the system

Start of works: 01.09.2010

Completion of works: 31.12.2010

Purpose and goals of creating the system

Purpose of the system

The automated system being developed is designed to automate the sales processes of an enterprise.

The goals of creating a system

Goals of creating an automated system

The goals of AS SBYT development are:

1. 3. Characteristics of the automation object

3.1 Business processes of the enterprise

3.1. 1 Business process "Conclusion of the contract"

It will become your shield, in this document you, in which case, you can point your finger at an unscrupulous developer and demand that your site be brought into line with it.

Technical task(shortly “TOR”) is a document that reflects the requirements for your future site in the most detailed and unambiguous way.

The site is created on the basis of TK. The more detailed and unambiguous it is, the more your new site will meet your expectations.

Terms of reference for the creation of the site - as a law, should not allow interpretations and discrepancies.

Everything that is not spelled out in the TOR, the developer does at his own discretion.

· Administrator's guide;

· Content Manager Guide;

· Installation guide;

· Programmer's guide.

2.20. Organization and conduct of training for specialists of the Investigative Committee under the Prosecutor's Office of the Russian Federation

The following training requirements apply:

· The Contractor must conduct training for employees of the Investigative Committee under the Prosecutor's Office of the Russian Federation, consisting of no more than 10 people.

· Training should be conducted in Russian.

· The room for training is provided by the Customer.

· Place and time of training must be agreed with the Customer.

Training should be conducted on all functionality of the System.

As part of the training, it is necessary to carry out the information content of one pilot site of the Ring of Sites of the Investigative Committee under the Prosecutor's Office of the Russian Federation.

3.

Sample terms of reference for website development

Important

During the implementation process, the Contractor shall provide assistance to the Customer within the framework of the Implementation Schedule.

6.1.11. In the event of poor preparation of the Customer's personnel for implementation and the need for additional assistance by the Contractor for the successful implementation of the software, an additional protocol for agreeing on contractual prices for the provision of information and consulting work should be drawn up.

6.2. The procedure for further support of the tasks of AS "SALES".

After the software is put into operation, additional improvements and wishes of the Customer can be implemented according to the TOR agreed with the Customer.

The TOR should indicate the labor intensity and cost of work to implement additional requirements.

6.2.2. The Contractor undertakes to maintain a telephone "hot line" for software maintenance.

Facets of interaction Before proceeding to the preparation of the process of creating a technical task, let's talk about the quadrangle, which the contractor and the customer fall into when starting the project. Requirements- the desired behavior of the system, as described by the customer or process holder, to be implemented. As a rule, requirements are formed on the basis of experience, representation of the correct behavior of the program.

This is key information for the developer (vendor), however, it is at the stage of collecting requirements that the largest number of collisions, errors, redundant requests, etc. occur.

Resources- people, machines, inventory, development environment, time and money to be used in the process of implementing the requirements. Resources require clear planning and evaluation at the stage of approval of terms of reference.

These include requirements for various kinds of sorting, chat integration, and telephony capabilities.

Service level- in fact, the requirements of this level should be the first to get into new builds with fixes. These are tasks in terms of system response speed, work under high load, and security.

Attention

Ideally, the vendor should not have such improvements - corporate software should not slow down, lose data, collapse forms and distribute access rights of the same level. But if a requirement has appeared, and it is not related to the personal paranoia of the customer or problems on the hardware side, it is worth paying special attention to it.

Technology level- the last in the list, but ahead of the rest in importance and complexity.

These can be client requirements related to the platform, operating system, or devices. For example, a build request for MacOS.

Microsoft World or Microsoft Excel.

Personally, when developing a landing page, we use special software products.

With their help, you can quickly and easily draft even complex sites - this is, for example, Balsamiq. However, how we make the entire prototype has already been described in the article.

On the subject: Site prototyping: creation, tools and programs.

Pre-project design can be done jointly with the developer or completely shifted to his shoulders.
The main thing, do not forget, then agree on it and sign it by both parties.

LIFE HACKS FOR DEVELOPING TOR

These points apply equally to both filling out the brief and drafting the terms of reference.

And in them I will reveal to you some tricks on how to create a technical specification for the site and make the already difficult life of an entrepreneur easier:

1.

Make sure that the client and the performer understand each other correctly.

The terms of reference should not contain high-quality adjectives: beautiful, reliable, modern. They cannot be clearly understood. Everyone has their own concepts of beauty and modernity.

Look. After all, someone thought this design was beautiful and allowed it to be used on their website:

The same thing - with slurred wording that does not mean anything by itself:

• The site must be liked by the customer. What if he's in a bad mood?
• The site must be user friendly. What does it mean? Convenient for what?
• The site must withstand heavy loads. 10 thousand visitors? Or 10 million?
• Quality expert content. Well, you get the idea.

Check for ambiguities in the text. If there is - rewrite.

Have you decided to order a website (aka a landing page)? As practice shows, it is not so simple. Hundreds of customers, having seen their finished site, find that it does not suit them: the design is not the same, the layout is lame, the texts are missing, they screwed a bunch of unnecessary functions.

To avoid such consequences, you need a technical task for the development of the site.

DO I NEED IT?!

It does not matter who will be the executor of the site - you yourself, your relative, freelancers for modest pay, a specialized company for a huge amount of money ...

The terms of reference for the site should be.

For example, you can ask to create a custom report for RegionSoft CRM, or you can order integration with the site. These are tasks that are completely different in terms of time, priority is very important here. After the requirements are collected, analyzed and agreed with employees and management, you can begin to create terms of reference.
You can either ask the vendor for the form or create it yourself - in any case, there are a few ironclad rules that will save both you and your CRM provider a headache.

Anatomy of a Terms of Reference

If we talk about the process of creating a technical task, then there are several stages. Their consistent passage leads the customer to the desired improvement.
Here they are.

Here it is important to listen to the opinion of the vendor, since he knows exactly how much time it will take for a particular task. Believe me, it is not profitable for a developer to play for time and wind up the deadline - it is beneficial for him to complete as many projects as possible and do it well so as not to get a blow to his reputation.

As for realism, avoiding requests to finish CRM to the level of a collider control system is simple: you should include in the requirements what is really needed at the moment and in the foreseeable future.

For example, RegionSoft CRM is a desktop program, we don't have a browser client. Asking us to create a web application for one company is pointless, this is a major development, it is currently underway and is not a possible refinement for one company.

Full and short name of the information system

The full name of the system is the official website of the Investigative Committee under the Prosecutor's Office of the Russian Federation.

The short name of the system is "Site SKP", "System", "Site".

1.2. Name of the customer of the system and his details

Name: Investigative Committee under the Prosecutor's Office of the Russian Federation

Location: Mr.

Info

Moscow, Technical lane, building 2

Actual address: A

Contact person of the Customer:

Phone: (4, (4;

E-mail address

1.3. List of documents on the basis of which the System is created

State contract No. ________________ dated ___ ___________ 2010

1.4.

Planned start and completion dates for the creation of the System

Determined in accordance with the Agreement.

2. System requirements

2.1.

payment date

Payment number

Payment number in the payment system

Amount of payment

1. Select Data Transfer File Lines
2. Start Looping Through Lines of Data Transfer File
3. Read line of data transfer file
4. Get the contract code from the line of the data transfer file
5. Find the corresponding element by code in the "Agreements of counterparties" directory, if the element is not found, then display the message "The agreement with the code was not found ..."
6. If the element is found, then add a line to the table of values, where: "Agreement" - the found element, "Date" - "Data_plat", "Payment Number" - "Nomer_plat", "Amount" - "Summa_plat"
7. After receiving the last line of the data transfer file, end the loop
8. For each line of the table of values, create a document "Payment order receipt of funds".

When filling out a brief or compiling a specification for the design of the site, do not leave spaces in it.

You must understand that “At the discretion of the developer” means “what I want, I turn back” or “Everything that is not specified is done at the discretion of the performer”. And believe me, this is not just a loophole, but a whole window to Europe for the developer.

And of course, this is not always the case.

If you got a competent specialist, then you can not worry about the result.

But here another problem arises, he can really do it right, but you will not like it purely subjectively. And everything will be like in a joke known to many developers:

BRIEFLY ABOUT THE MAIN

You will definitely not regret the time spent on compiling and agreeing on the terms of reference for creating a website or landing page.

After all, this is your best tool for controlling and resolving disagreements that arise in the process.

When you click on a particular district, it should go to a page with a text description of this district.

· Block "Chairman's Blog"- should be a list of the last three topics created on the blog in the form of a topic name and the date it was published. The title of the topic will be a link, when clicked, it should take you to the blog page with a description of this topic. Also, this block should contain a video that can be played without leaving the main page. The video must have a "Comments" link, which is the number of comments on the video. The "Comments" link should lead to a blog page with comments on the submitted video.

The footer should contain a search field, copyright information, etc.

2.3.

brief- this is a questionnaire with questions about the content, design, technical capabilities of your future site.

Of course, a detailed brief, signed by both parties, can replace the terms of reference.

After all, this is practically the same, the only difference is that the brief is your vision, and the terms of reference is the final document based on your brief and the developer's comments themselves.

If certain points cause difficulties, then do not hesitate to ask the developer questions like “What does this mean?”, “How will this affect the operation of my site?”, Since not all developers understand the same thing as you.

Or in the column “Additional information” be sure to indicate all your wishes that were not included in the answers to the questions.

If this column is missing, just add them at the end of the brief.

VK, Google, Facebook.

3.2.2 In your personal account in the orders section, add a field for adding a promo code.

3.2.3 Instead of the page that comes to the user after a password recovery request (of the form name.com/bitrix/admin/index.php?change_password=yes&lang=ru&USER_CHECKWORD=), make a page (of the form name.com/login/forgot/change_password=yes&lang =ru&USER_CHECKWORD=), which will display the content of the site, will have the "Email during registration" field, a control string, a new password, a password confirmation, a button to send data.

3.2.4 When adding items to the cart, a message should be displayed stating that the item has been added to the cart.

3.2.5 Add a message that the password does not match the security settings when registering a new user.

automatedSALES system.Technical task On sheets Valid from "__" ____________ 2010

» _» ______________ 2010

Gradually, the changes were included in the release, and later allowed to create a new product for wholesale, retail stores and hypermarkets - RegionSoft Retail.

User or user group level. At this level, tasks are implemented to refine the existing interface. For example, a user may want a window with the number and status of the last order to appear when hovering over a customer, or a custom report with a special grouping of data.

Improvements at this level take less time, but there can be a lot of them - for example, several requirements from the marketing, logistics and technical support departments.

functionality level. It is often difficult to separate it from the previous one, a formal criterion works here - refinement is not at the level of displaying something in the interface, but at the level of refinement of the system logic.

If porridge is written there, it might be worth running and not looking back.

• To insure against dishonesty of the performer. When the site is ready, it can be checked according to the terms of reference. Are there inconsistencies? The developer must fix them. If you cooperate officially and entered into an agreement, you can even be forced through the courts.
• Simplify the replacement of performers. If the client and the developer quarreled and fled, the creation of the site can take a long time. When there is a detailed terms of reference, it can be transferred to a new team - it will get involved in the work many times faster.
• Find out the cost of developing a complex product. It is impossible to estimate the exact timing and cost of developing a complex web service right off the bat. First you need to understand how the service will work, and what functions it will have.

There is root access, private IP addresses, ports, filtering rules and routing tables.

Google PageSpeed ​​Insights is a free recommendation service for websites to speed up page rendering in the user's browser (https://developers.google.com/speed/pagespeed/insights/).

Search engine optimization (or SEO) is a set of measures for internal and external optimization to raise the position of the site in the results of search engines for certain user requests.

External site optimization is site registration in search engines, promotion in social networks, link building by attracting links from other resources to the site being promoted, banner advertising, contextual advertising.

Internal site optimization is the optimization of text, URLs, editing the site structure, relinking, checking server responses.

Available materials Links to the sites you like, as well as booklets, magazines, photographs - anything, or maybe you have a ready-made brand book. Attached in a separate archive. Minimum resolution and display devices In this paragraph, specify the devices from which you intend to view the site - PCs, laptops, smartphones ... PC monitors from 19 to 27 inches; Notebooks from 15.6 to 17.3 inches; Smartphones from 3.5 to 6 inches; Tablets from 7 to 12 inches Do you need a mobile version? Yes FUNCTIONAL REQUIREMENTS Approximate set of modules (for users) In this section, you need to list all the functionality that you want to see on the site.

This can be a shopping cart, catalog filters by various parameters, the ability to place an online order, leave a request for a call back, subscribe to a newsletter, and any other options. Catalog filters by price, alphabetically, by manufacturer.
CRUпtCj9B:s»XVzhb╟▌╤└u╟J_■E╘Dj»J■╛EXHJya(gTT┬Pb╟▌╤└u╟╛#╜┘al+Kqяk3┴i≈²&F╒#┐╜╙┐█ ts╜IWA▓BOЬ└vOЗb╟▌╤└u╟╛#╜┘al+КaXG[ b:ьVzhb╟▌╤└u╟╛#╜┘al+КaXG[ b:ьVzhb╟▌╤└u╟╛#╜ . #╜┘al+KaXG[ b:bVzhb╟▌╤└u╟╛#╜┘al+KaXG[ b:bVzhb╟▌╤└u╟╛#╜┘al+KaXG[ b:bVzhb╒▀┬y╥XuF ≈≈K&ОQТё╦▒'%[n╓≥Lk"[Ts(b╖~s╚b╖~s╚b╖~s╚b╖~s╚b╖~s╚b╖~y╚b╖~y ╚b╖~s╚b╖~s╚b╖~s╚b╖~s╚b╖~s╚b╖~s╚b╖~s╚b╖~s╚bD'═\┘*NlkZ ⌡ . . ©OlM²K%j ┼╖`СsА≈K▐f²Yh▐Hd╟Fg╬lн∙╥е#⌡i<ТC▐╡И&d╨JГ!─Sj║·K,s┼#m ╓⌡JГн IOLЬ©h?ОeН╡▐┌ъHЙmwд$©aЗ$ёу°Н≤gт.bZ┐}Э1црn▄т≈фГ?TA<э:р▓T<кГ║2ic╖▀Иqf⌠Pсс▀32нЫ╘▌n-«÷0i╦▓Q:⌠^%5#⌡Н⌡│ вЬ└%N╙Оtб}8яца╨з≤[╖┐╕■╡╒4╞▄G√≥оЖNa╡vсM╔)9╘д≈ib╕╝■ i├{≈²5╨∙∙╣ф╒▓Цz²┌Ф╤I√HaО2┬б=└Б╦F∙P»гЙz&╔Р3{ ёS÷_н_g7⌡г$Н╜чk┐(ЗQэH▓З╨?.

In view of the fact that they are often asked to give examples of TK, I share with the community some of my developments. These documents have no commercial value (because of the limitation of years and configuration), but I hope they can be useful as samples.

Technical task:

automated

SALES system.

Technical task

On sheets

"_" ______________ 2010

1. General information

Name of the automated system

"AS SALES"

Customer

Executor

Basis for work

Scheduled dates for the start and completion of work on the creation of the system

Start of works: 01.09.2010

Completion of works: 31.12.2010

Purpose and goals of creating the system

Purpose of the system

The automated system being developed is designed to automate the sales processes of an enterprise.

The goals of creating a system

Goals of creating an automated system

The goals of AS SBYT development are:

1. 3. Characteristics of the automation object

3.1 Business processes of the enterprise

3.1. 1 Business process "Conclusion of the contract"

3.1.2. Business process "Payment"

1. 4. system requirements.

4.1. General system requirements.

4.1.1. The methods and software modules developed in the AS should contain the possibilities for further development of the system.

5.1.1. The developed system should consist of automated systems, subsystems and accounting modules allocated according to their functional purpose in accordance with the established methodology for building automated systems of the financial and economic class.

5.1.2. The developed AS should provide ease of setting up an automated workstation (AWP) for each specific performer in accordance with the existing accounting system.

5.1.3. The AS being developed should ensure the differentiation of user access rights and provide the ability to access information to the extent necessary and sufficient for the performance of the duties of each performer.

5.1.4. Protection of information from unauthorized access should be implemented using the following mechanisms:

1. Access rights restrictions at the 1C:Enterprise platform level 8.1.

2. Additional restrictions on access rights at the level of the execution environment.

5.1.4.1.Priority should be to restrict access rights at the platform level. Removing additional restrictions at the runtime level does not give access rights to objects or functions of the system if a system restriction is imposed on them.

5.1.4.2 Information security at the platform level

· Protection of information at the platform level is provided by system tools. At the same time, the rights to read and edit system objects, use interfaces, system functions and perform routine operations with information system data are regulated.

· All access rights should be systematized into appropriate sets - Roles of the information system.

· The list of information system users must be determined by the system administrator.

· The access rights of each user must be determined by the set of Information System Roles available to him.

· The sets of Information System Roles available for each user must be determined by the system administrator.

· When starting to work in the system, the user must go through the authorization procedure, indicating his name in the system and password.

5.1.4.3. Protection of information at the runtime level

For a number of directories in the system, additional restrictions on editing rights should be provided.

Directories for which it is necessary to set a ban on editing in the system:

• Address abbreviations
• Currencies
• Types of mutual settlements
• Activities of counterparties
• Groups of users
• Identity documents
• Positions of organizations
• Subdivisions
• Users
• Cash flow items
• Expenditures
• Tariffs

5.1.5. To ensure the safety of information in case of accidents, daily automatic data archiving should be provided.

5.1.6. Requirements for ergonomics and technical aesthetics

5.1.6.1. To ensure the unification of the design of user interfaces, toolbars and context menus automatically generated by the 1C platform should be used by default.

5.1.6.2. The terminology used to designate objects and user actions in the system must comply with the standard terminology of the subject area.

5.2. Requirements for the structure and functioning of AS "SBYT".

5.2.1. AS "SALES" should consist of the following automated subsystems:

Subsystem for entering primary information about the subscriber (concluding an agreement);

Subsystem for generating documents for payment;

Communication subsystem with ASKUE system;

Subsystem for communication with payment terminals.

5.2.2. The composition of the Subsystem for entering primary information about the subscriber (concluding an agreement) should be as follows:

Document "Agreement with the subscriber";

5.2.3. The composition of the Subsystem for generating documents for payment should be as follows:

Document "Receipt"

Document "Charge of Penalties"

Document "Consumed energy"

Module for checking the status of mutual settlements

5.2.4. The composition of the Communication Subsystem with the ASKUE system should be as follows:

Module Communication with ASKUE system.

5.2.5. The composition of the Subsystem for communication with payment terminals should be as follows:

Module Communication with payment terminals.

5.3. Requirements for the functions of the module of the Subsystem for entering primary information about the subscriber (concluding an agreement)

5.3.1. The subsystem for entering primary information about the subscriber (concluding an agreement) should perform the following functions:

Entering and storing information about the installed capacity of the counterparty (hereinafter referred to as the subscriber);

Entering and storing information about the subscriber's installed counters;

Entering and storing information about the subscriber's tariffs;

Entering and storing information on the conditions for calculating penalties for the subscriber;

Entering and storing information about the terms of the contract;

5.4. Requirements for the functions of the Subsystem for generating documents for payment

5.4.1. The subsystem for generating payment documents should perform the following functions:

Determining the status of mutual settlements with the subscriber and determining the conditions for the occurrence of penalties.

Formation of documents for payment (receipts or invoices for payment).

5.5. Requirements for the functions of the Communication Subsystem with the ASKUE system

5.5.1. Subsystems for communication with the AMR system should perform the following functions:

Transfer of data on newly concluded contracts with subscribers. The communication key must be the uniqueness of the pair "Subscriber ID" - "Subscriber Agreement Code".

Obtaining data on the consumed electricity by the subscriber. The communication key must be the uniqueness of the "Meter ID" - "Meter Code" pair.

5.6. Requirements for the functions of the Subsystem for communication with payment terminals

5.6.1. Subsystems for communication with the AMR system should perform the following functions:

Obtaining data on payments made by subscribers for electricity through payment terminals.

1. 6. Procedure for control and acceptance of AIS "SALES".

6.1. The following procedure for presenting and handing over the results of work to the Customer is established:

6.1.1. The Contractor demonstrates the operability of the software on a control example.

6.1.2. The data for the test case is prepared by the Customer's representatives.

6.1.3. The Contractor transfers the software to the information department of the Customer and trains the Customer's administrator.

6.1.4. Based on the results of solving the test case, an Act on the transfer of software for trial operation should be prepared.

6.1.5. In case of discrepancy between the functionality of the software and the requirements of the TOR, the Contractor performs the elimination of comments as part of the total cost of developing the AS.

6.1.6. If there are additional requirements of the Customer to the TOR, an additional TOR for revision is drawn up.

6.1.7. The presence of additional requirements of the Customer should not be the basis for refusing to sign the Act on the transfer of software for trial operation.

6.1.8. After the transfer of the software for trial operation, according to the Implementation Schedule agreed with the Customer, the Contractor performs a brief training of the Customer's personnel to work with the software and transfers the Instructions for working with the software to each subsystem.

6.1.9. When implementing the software (trial operation), the Customer performs:

Entering the required NSI;

Entering actual data;

Formation of reports and verification of the results of work.

6.1.10. During the implementation process, the Contractor shall provide assistance to the Customer within the framework of the Implementation Schedule.

6.1.11. In the event of poor preparation of the Customer's personnel for implementation and the need for additional assistance by the Contractor for the successful implementation of the software, an additional protocol for agreeing on contractual prices for the provision of information and consulting work should be drawn up.

6.2. Procedure for further support of AS "SALES" tasks.

6.2.1. After the software is put into operation, additional improvements and wishes of the Customer can be implemented according to the TOR agreed with the Customer.

The TOR should indicate the labor intensity and cost of work to implement additional requirements.

6.2.2. The Contractor undertakes to maintain a telephone "hot line" for software maintenance.

6.2.3. At the request of the Customer, the Contractor may carry out software maintenance directly at the Customer, which should be carried out on the basis of an additional software maintenance agreement.

6.2.4. Errors identified by the Customer within six months from the date of transfer of the software to operation must be eliminated by the Contractor promptly and free of charge.

In the event that the Contractor discovers that the error arose as a result of incorrect actions of the Customer, the time spent by the Contractor to find and eliminate it must be paid additionally.

6.2.5. The customer, within a year after the purchase of 1C: Enterprise, has the right to receive free of charge all updates from 1C related to the development of 1C programs and changes in legislation. The installation of changes must be carried out by the Customer's automated control system.

6.2.6. The Contractor guarantees the confidentiality of the content of the Customer's databases and any other information received from the Customer in the process of developing, implementing or maintaining the AS.

Technical project:

APPROVE SUBMIT FOR APPROVAL

""______________ 2010" ""_______________ 2010

Annex to the terms of reference dated "____" ________ 2010

automated

SALES system.

Technical project

On sheets

Valid from "__" ____________ 2010

Reference books. 3

Counters. 3

Tariffs.. 3

Substations. 3

Penalty options. 3

Enumerations. 4

Types of accruals. 4

information registers. 4

Meaning of Tariffs. 4

Subscriber rates. 4

Meters data. five

Accumulation registers. five

Power consumption. five

Documents.. 6

Agreement with the subscriber.. 6

Consumed Energy. 6

Receipt. 7

Calculation of penalties. nine

Processing. 10

Obtaining data from the ASKUE system. 10

Receiving data from the payment system.. 11

Reference books

Counters

Requisites:

Tariffs

Details: no

Penalty Options

Details: no

Enumerations

Types of accruals

Values:

Information registers

Terms of contracts

Periodicity: Non-periodic

Purpose: Designed to store the validity of contracts with subscribers

measurements

Meaning of Tariffs

Frequency: Day

Purpose: Designed to store tariffs and dates from which tariffs begin to operate.

measurements

Props		Purpose
		Daily rate cost
		Night rate cost (may not be set)

Subscriber tariffs

Frequency: Day

Purpose: Designed to store the tariffs assigned to the subscriber in accordance with the agreements

measurements

Props		Purpose
	Directory Tariffs	Subscriber tariff

Meters data

Frequency: Day

Purpose: Designed to store meter readings for subsequent billing

measurements

Props		Purpose
ReadingsDay		Counter reading
ReadingsNight		Counter reading

Accumulation registers

Power consumption

Purpose: Designed to store information about energy consumption for subsequent billing

Register type: negotiable

measurements

The documents

Contract with a subscriber

Purpose: Designed to reflect the fact of concluding an agreement with a subscriber

Props		Purpose
counterparty	Directory Counterparties
Counterparty Agreement
	Directory Tariffs
InstalledPower		Storage of the subscriber's installed capacity in kWh
DateStartActions		Date from which the contract is valid
End DateActions		Contract expiration date
Organization	Organization Directory
OptionAccrualFine
Nomenclature	Directory Nomenclature
Manual Adjustment		Sign of manual adjustment of document postings

Tabular part: Meters and Tariffs

Document holding

The document is held:

According to the register of information "Meter readings" where he prescribes the subscriber's counters and the initial meter readings;

According to the information register “Subscriber Tariffs”, where the tariff set for the subscriber is prescribed from the date the contract began to operate

According to the information register “Validity of contracts”, where the contract is written, the date of commencement of validity and the date of expiration of the contract

Consumed Energy

Purpose: Designed to reflect meter readings on a specific date

Filling out a document

The document can be filled in in two ways: by manual entry and by calling the processing "Obtaining data from the ASKUE system"

Document holding

The document is held:

According to the register of information "Meter readings" where he prescribes the meter readings on the date of the document;

According to the accumulation register “Consumed energy according to the following algorithm:

1. The meter readings are taken from the information register "Meter Readings" on the date of the document and the previous value of the meter readings.

2. Differences in reading values ​​are recorded in the corresponding resources of the accumulation register.

Printing forms

Register of meter readings

Receipt

Purpose: Designed to reflect charges to subscribers

Filling out a document

The document can be filled in in two ways: by manual entry and by calling the processing "calculation of payment"

Tabular part: Meter readings

Props		Purpose
counterparty	Directory Counterparties
Counterparty Agreement	Directory Contracts of counterparties
Nomenclature	Directory Nomenclature
	Directory Tariffs	Subscriber's tariff according to the agreement
	Directory Counters
TypeAccruals	Enumeration Types of Accruals
ConsumedEnergy		Consumed energy
Tariff value		Tariff value on document date
accrued		The amount charged to the subscriber

Document holding

The document is held:

According to the chart of tax accounts:

Printing forms

Register of accruals

Fill algorithm

The document is filled out on the basis of the directory "Agreements of counterparties".

1. Contracts are selected from the directory, for which, according to the information register “Terms of validity of contracts”, the Start Date is less than the document date and the End Date is greater than the document date;
2. Counters corresponding to these contracts are selected;
3. For meters, energy consumption is determined as turnover according to the accumulation register "Energy Consumption" for the period between the date of the document and the date of the previous document, if the date of the previous document is unknown, then the entire turnover according to the register is taken. The resulting value is recorded in the field "Consumed Energy"
4. The tariff is set according to the contract and the value of the tariff on the date of the document;
5. Sets the type of accrual "According to meter readings";
6. The Accrued Field is calculated as the product of the Consumed Energy and the Tariff Value.

Carrying out algorithm

ct. 90.01 with analytics SubcontoKt1 - Nomenclature.NomenclatureGroup, SubkontoKt2 - Nomenclature.VAT rate.

If there is a Credit balance On account 62.02, then the advance payment is offset with the posting

Dt. 62.02 with analytics SubcontoDt1 - Counterparty, SubcontoDt2 - Counterparty agreement

Posting amount - the minimum value from the credit balance on account 62.02 and the value of the attribute "accrued")

Dt. 90.03 with analytics SubcontoDt1 - Nomenclature.NomenclatureGroup, SubcontoDt2 - Nomenclature.VAT rate

ct. 62.01 with analytics SubcontoKt1 - Counterparty, SubkontoKt2 - Counterparty agreement

Posting amount = "Accrued" * VAT rate / (100 + VAT rate), where VAT rate - "Nomenclature. VAT rate"

Calculation of penalties

Purpose: Designed to reflect the accrual of fines to subscribers

Filling out a document

The document can be filled in in two ways: by manual entry and by calling the processing " accrual of fines"

Tabular part: Meter readings

Props		Purpose
counterparty	Directory Counterparties
Counterparty Agreement	Directory Contracts of counterparties
OptionAccrualFine	Directory Penalty Options
accrued		The amount charged to the subscriber

Document holding

The document is held:

According to the chart of accounts self-supporting:

According to the chart of tax accounts:

Printing forms

Register of accruals

Payment receipt with barcode

The barcode is generated using the font "Infograftbarcode"

Formation algorithm String "0000"+Subscriber contract code+Charged

The layout of the receipt is attached in the file КВ_1.mxl

Carrying out algorithm

For each line of the tabular section "Meter Readings", the following entries must be made:

Dt. 62.01 with analytics SubcontoDt1 - Counterparty, SubcontoDt2 - Counterparty agreement

ct. 91.01 with analytics SubcontoKt1 - Other income.

Posting amount - the value of the attribute "Accrued";

Processing

Receiving data from the ASKUE system

			Accuracy	Purpose
				The meter code in the "Sales" system, matches the meter_ID in the ASKUE system
				Daily meter readings
				Night meter readings

Processing details

Processing algorithm:

1. Get the counter code from the line of the data transfer file
2. Find the corresponding element in the “counters” directory by code, if the element is not found, then display the message “Counter with the code was not found ...”
3. If the element is found, then add a line to the table of values, where: "counter" - the found element, "IndicationsDay" - "Day", "IndicationsNight" - "Night"
4. If the processing is called from the document "Consumed Energy" and the number of lines

in the table of values ​​greater than 0, then write the contents of the table of values ​​in the tabular part of the document and post the document.

1. If there are rows in the value table and the processing is not called from the Energy Consumed document, then create the Energy Consumed document with the date equal to the current date and then post the document.

Receiving data from the payment system

The data transfer file format is DBF;

Data transfer file structure:

Processing details

Processing algorithm:

1. Create value table with structure:

1. Select Data Transfer File Lines
2. Start Looping Through Lines of Data Transfer File
3. Read line of data transfer file
4. Get the contract code from the line of the data transfer file
5. Find the corresponding element by code in the "Agreements of counterparties" directory, if the element is not found, then display the message "The agreement with the code was not found ..."
6. If the element is found, then add a line to the table of values, where: "Agreement" - the found element, "Date" - "Data_plat", "Payment Number" - "Nomer_plat", "Amount" - "Summa_plat"
7. After receiving the last line of the data transfer file, end the loop
8. For each line of the table of values, create a document "Payment order receipt of funds". When creating a document, check whether the system has a document with such a date and such an incoming document number. If the document is present in the system, then the document is not created.
9. Rules for filling out the details of the document:

Props	Fill value
Type of operation
	RowTableValue.Date
Incoming document number	StringTableValue.PaymentNumber
Date of incoming document	RowTableValue.Date
Counterparty agreement	StringTableValue.Contract

It directly depends on how accurately the terms of reference for finalizing 1C are drawn up, whether the tasks assigned to the developers will be solved. However, when working with such a document, there are some difficulties. In a broad sense, the TOR prescribes the norms for the creation and modernization of an automated system (AS), as well as the procedure for work. This also includes a set of project launch standards. This understanding of the role of the terms of reference is dictated by the requirements of GOST 19.201-78 and 34.602-89, according to which the TOR for 1C is being developed. There is another interpretation of the meaning of this document, closer to practice.

According to another definition, the terms of reference for finalizing 1C is a document that regulates the purpose and parameters of the future system, as well as the process of developing documentation and its list. This interpretation allows taking into account the interests of programmers and the customer.

What should be the TK?

Any technical task for the development of the 1C program is created by the contractor. But this is not a programmer, but an analyst. This is an important point, because the document must be written in a language that the client understands, without highly specialized technical terms. When all the nuances of the project are taken into account and the information is formulated correctly, the TOR is agreed with all customers. If it is accepted, programmers are involved in the work. At the same time, the desired result should be clearly outlined in the document. This helps developers set the right goal and check against it at different stages. Also, when drawing up the terms of reference for finalizing 1C, much attention should be paid to the wording. Care must be taken to ensure that they are sufficiently specific and do not imply other interpretations. This is the first thing to remember when working with TK. You also need to take a responsible approach to the design. This also applies to the title page of the document.

The main mistakes in the terms of reference for the development of 1C

The structure of the terms of reference is regulated by GOST 34.602-89. This document contains clear requirements for the number and sequence of blocks of information in the TOR. At the same time, there are no strict standards for presentation methods. This situation contains great potential for solving complex problems and at the same time can lead to many errors in the preparation of the document. The most common inaccuracies are:

1. Repetition of some sections in different interpretations.
2. The information is given randomly. Ideally, it should refer to a specific structure, such as business processes or system modules.
3. Information in different sections is presented with varying degrees of detail.

All this prevents the customer from understanding the information that is set out in the TOR. This complicates the process of cooperation, making it more time-consuming.

After viewing by the customer, the sample TOR for revision of 1C may change and not always for the better. This, in turn, usually prevents programmers from correctly perceiving information. This is especially true for specialists with little experience. At this stage, the following errors often occur:

1. The requirements of different sections contradict each other.
2. The formulas are inaccurate.
3. In some places, the information is too detailed.

Getting rid of all these errors is easy. It is necessary to focus, first of all, on the result, and not on carefully prescribing formulations. It is worth remembering that the TOR describes the functionality of the project, its main parameters and purpose.

How to avoid mistakes in the development of technical specifications?

The main rule, which applies to all subsequent recommendations, is that the wording should be specific. To do this, you need to use links to GOSTs, other regulatory documents. This allows the contractor and the customer to perceive information in the same way.

An example of a technical task for finalizing 1C involves the use of the language of the business industry for which the project is being implemented. This is necessary, first of all, for the customer. At the same time, you should not use any comparisons in the text, since they can be interpreted in different ways.

Basic rules when drawing up terms of reference for the development of a report and other elements of 1C:

1. TK is created jointly by the contractor and the customer.
2. Only objective requirements should be presented to the work of programmers. For successful project development, the subjective vision of the customer must be kept to a minimum.
3. It is necessary to describe in detail the result that the customer needs. At the same time, in the example of the terms of reference for the development of the 1C configuration, it is necessary to prescribe all the parameters by which the element should work. Otherwise, the result may be very different from the desired.
4. The risks of the contractor and the customer should be approximately equal and minimized.
5. You can not use terms that are used in business communication and are not used in a particular industry.

To create a TOR for the development of a report in 1C or another element, the analyst must know all the features of the customer's field of activity. In the requirements, you need to give only useful information that is useful to the performer. Given that special attention is paid here to the final tasks that the software must solve, there is no single example of a technical task.

The danger of incorrect preparation of TOR

The errors listed above can lead to an increase in the time it takes to create a system. This entails unnecessary costs and dissatisfaction. The terms of reference for the development of a database or other 1C configuration should be drawn up by experienced specialists. The benefit of all participants depends on how this document is understandable. The customer receives an effective automated system for solving business problems. At the same time, the contractor has another satisfied client. Business owners need to be as careful as possible when choosing 1C partner companies, because the effectiveness of the organization largely depends on how well the terms of reference for revision are drawn up.

If you go through foreign sites with the request “product requirements document”, you can find creative and convincing articles about the fact that the technical task (TOR, PRD) is dead. In part, we have to agree with this - when developing a product from scratch, prototyping looks much more interesting and efficient than volumes of customer records, sometimes very unprofessional ones. However, if we are talking about finalizing the basic system, then things take a completely different turn. We are faced with both revision and custom development, so the dog was eaten at the TK, if the cook does not lie to us. In general, today - about those very classic technical tasks that are written to finalize the purchased and installed software. In short, about the sore.

Facets of Interaction

Before proceeding to the preparation of the process of creating a technical task, let's talk about the quadrangle, which the contractor and the customer fall into when starting the project.

Requirements- the desired behavior of the system, as described by the customer or process holder, to be implemented. As a rule, requirements are formed on the basis of experience, representation of the correct behavior of the program. This is key information for the developer (vendor), however, it is at the stage of collecting requirements that the largest number of collisions, errors, redundant requests, etc. occur.

Resources- people, machines, inventory, development environment, time and money to be used in the process of implementing the requirements. Resources require clear planning and evaluation at the stage of approval of terms of reference. Competent prioritization on the part of the customer and the distribution of labor resources on the part of the vendor make it possible to avoid missed deadlines and minimize other risks.

Opportunities- in short, this is what a vendor (performer) can really do. Consider our RegionSoft CRM as an example. The client buys the system and draws up a technical task for revision: it is necessary to create an integration with the site and link events in CRM to the order number of the online store. This is a realistic requirement, we have the resource and the ability to do it. And you also need to develop and tie to CRM CMS, a site content management system. Theoretically, we can do this, but we do not have the opportunity to do it cheaply, and the client does not have the opportunity to pay us enough to transfer human and time resources to the task. As a result, the customer refuses this requirement - and he doesn’t really need a CMS, everything is fine anyway. But about the "greed" of TK - later.

Restrictions- a set of obstacles that make it difficult or impossible to complete tasks from the TOR: budget, technology stack, licensing problems, legal prohibitions, hardware configurations, etc.

Thus, all four entities are closely intertwined and determine the success of the project as a whole. Let's consider each element and try to highlight the critical points that need to be kept in mind when working on the terms of reference.

Collection and analysis of requirements

This is a very important internal corporate process, during which it turns out what potential users want from the program (hereinafter, we will take CRM, but the methods work with other types of software). If you contact a large vendor such as SAP or a system integrator, then with a high degree of probability you will be offered the services of a business consultant (he is also a personal manager, he is also an account manager, he is also “now your representative in our company”). In fact, in most cases, this is an ordinary well-trained salesman who has two tasks: to wind up the cost of the project and not let you off the hook.

He's been here for an hour and hasn't even touched the whiteboard. He's not a real systems analyst

Nobody knows your company better than you and your employees. This means that the collection and analysis of requirements is exclusively your task, in which the vendor can help and guide, but in no case interfere with the process. Ask the developer about such implementations, specify what to look for and proceed. By the way, your employee who is well versed in the profile topic and roughly represents the software architecture and is familiar with the development process can be a good assistant - he can act as an analyst and internal expert, close the process of creating technical specifications and communicating with the vendor.

There is a very simple scheme for collecting requirements.

1. Create a working group of managers and experienced specialists of departments who will use CRM. Tell us about the solution you are going to choose, provide access to the demo version.
2. Members of the working group must convey information to employees and ask them for wishes for a new program in an absolutely free form. If one of the employees has never encountered such software and is not ready to talk about future use, you need to ask him to describe his periodic tasks, this is a universal approach.
3. Each division then determines what the CRM does not or does not match and aggregates the information.
4. The working group analyzes the collected requirements, checks and eliminates intersections. For example, it is not uncommon for a sales department and a marketing department to order the same report, but fields and entities may be named differently in the requirements, although the data behind them is the same. Accordingly, it is necessary to come to a single form.
5. The working group forms a list of requirements and sets priorities. At this stage, you can connect the vendor, since he is responsible for the resources. For example, you can ask to create a custom report for RegionSoft CRM, or you can order integration with the site. These are tasks that are completely different in terms of time, priority is very important here.

After the requirements are collected, analyzed and agreed with employees and management, you can begin to create terms of reference. You can either ask the vendor for the form or create it yourself - in any case, there are a few ironclad rules that will save both you and your CRM provider a headache.

Anatomy of a Terms of Reference

If we talk about the process of creating a technical task, then there are several stages. Their consistent passage leads the customer to the desired improvement. Here they are.

• Identification - definition of requirements, search for problems that need to be solved.
• Analysis - analysis of requirements, identification of key needs, generalization.
• Adaptation - assessment of requirements in the context of CRM capabilities and existing business processes.
• Documentation - a formal and detailed description of requirements, approval of technical specifications.
• Communication with the vendor (developer) - iterative interaction with the vendor regarding improvements in accordance with the compiled TOR.
• Implementation - the work of the vendor to create the necessary functionality. It is better if the vendor is constantly in touch with the customer - so the output product will most closely match the client's vision.
• Testing - checking the functionality by the vendor's employees, the client's internal experts and end users in order to establish the compliance of the revision with the TOR, the system's operability with changes.

In general, the terms of reference can be created based on the requirements of several levels, which may overlap and cooperate in the creation of the project or not interact at all.

Business level- the most global level at which complex and priority tasks are solved. This level includes integration, refinement and modeling of business processes, development of new functional modules. As a rule, this is a resource-intensive development, with serious consultations and close collaboration with the customer. For example, at one time in RegionSoft CRM, warehouse accounting, cash register and production were such custom modifications. Gradually, the changes entered the release, and later allowed the creation of a new product for wholesale, retail stores and hypermarkets - RegionSoft Retail.

User or user group level. At this level, tasks are implemented to refine the existing interface. For example, a user may want a window with the number and status of the last order to appear when hovering over a customer, or a custom report with a special grouping of data. Improvements at this level take less time, but there can be a lot of them - for example, several requirements from the marketing, logistics and technical support departments.

functionality level. It is often difficult to separate it from the previous one, a formal criterion works here - refinement is not at the level of displaying something in the interface, but at the level of refinement of the system logic. These include requirements for various kinds of sorting, chat integration, and telephony capabilities.

Service level- in fact, the requirements of this level should be the first to get into new builds with fixes. These are tasks in terms of system response speed, work under high load, and security. Ideally, the vendor should not have such improvements - corporate software should not slow down, lose data, collapse forms and distribute access rights of the same level. But if a requirement has appeared, and it is not related to the personal paranoia of the customer or problems on the hardware side, it is worth paying special attention to it.

Technology level- the last in the list, but ahead of the rest in importance and complexity. These can be client requirements related to the platform, operating system, or devices. For example, a build request for MacOS. It's great if such requirements gradually develop into releases, but it is necessary to have their fixes. It was from the requests of clients at this level that we made an assembly of RegionSoft CRM for MacOS and added remote access using TRM technology as a temporary solution to a rare, but existing request for a mobile version.

The anatomy of the terms of reference is simple, at least in the form of a skeleton. Mandatory parts of the terms of reference help the customer to focus on the problem and formulate the task correctly, and the performer to understand what they want from him. By the way, about understanding. Of course, at the beginning of the post, we were a little cunning, denying business consultants as a class. The point is this: each vendor has been operating on the market for several years (we are not talking about one-day CRMs now), or even decades, which means that it has a set of cases in almost every industry. Accordingly, both engineers, programmers, and salespeople are familiar with the specifics of implementation in each type of company. But again, it is important to focus on your business.

For whom? In this section, you need to describe who will be the end user of the revision, what tasks and how often it is planned to solve.

I'll give you an example. One company implemented CRM, it was supposed to work on a fairly large array of data (several tens of millions of records per month, several hundred thousand records per day). The head of the sales department requested a report on the upload of these records with a frequency of "daily". Naturally, such a report, while hundreds of users were working simultaneously, loaded the system - solutions were found to optimize the process. Already in the course of work, it turned out that the salesman was playing it safe and he needed the report only at the end of the month, and then it could be launched according to the schedule at night. Needless to say, time and money were wasted.

What for? Justification of the need for improvement and its place in the business process. This item is more needed by the customer himself, but it is also useful for the vendor to know what other processes will be affected. Sometimes it helps to find an alternative solution.

What should be done? The most informative block - it describes the requirements, expectations from the system. And here the very pearls, miracles and collisions happen, which are just right to send to the bashorg, and which, well, make life very difficult. There is only one reason - the user does not know what he wants, what needs to be done. There is another small sub-reason - the user cannot formulate requirements. And here the task of the developer (working group, analyst, if any) is to help formulate the need correctly, select an appropriate requirement, and fit the task into the context of the system. In the same block, you need to mention the expected result.

Terms of reference parameters- deadlines, stages of implementation, responsible from all parties, necessary contacts, etc. In fact, this is a set of important formal things that make the document a technical task. The terms of reference must be agreed upon and signed by the parties in order to avoid numerous changes during development (they will still be, but in a smaller volume).

Ideally, the terms of reference are drawn up with the active participation of the vendor, and its result is approximately the following structure:

1. Description of the requirement of each mechanism and each functionality
2. Description of the implementation of this functionality
3. The cost of work for each of the stages separately
4. The total cost of work on this technical task
5. Deadlines for the execution of work with a breakdown by stages and an indication of the order of priority
6. Description of installation and testing conditions
7. Reservations on the exhaustive nature of the terms of reference and other conditions

10 Rules Written in Developer's Tears

Terms of reference for revision should be TOR for revision, and not a 300-page description of the CRM that the client needs. Before drawing up requirements, you should carefully familiarize yourself with the system interface, its capabilities, documentation - most likely, most of the "Wishlist" is already in the basic package. As a second step, I would recommend paying attention to the built-in refinement tools (report designers, configurators, etc.) - perhaps a full-time programmer will be able to make the necessary changes (many companies have them).

The technical task should not be greedy. Often, a business overestimates its capabilities or wants to get "everything at once." This approach is not justified either from the point of view of money or from the point of view of business. A vendor, as a rule, does not exist for a couple of weeks (in the case of RegionSoft - 15 years), and you can contact him even after a while, when you really understand what is missing in CRM.

A vivid example of redundancy literally from yesterday: a client bought the ERP of a well-known Russian company, thinking that since accounting works, then the ERP of this vendor will be good. ERP turned out not to be not very good in itself, but very unsuitable for business. But RegionSoft CRM with warehouse accounting and production is suitable. There is a solution: forget about ERP, cry, integrate 1C accounting with the new CRM and enjoy the convenient implementation. But the swollen money is a pity! And the client demands to integrate CRM with ERP. We didn’t do that, but why such a waste, why two relatively similar systems?

Terms of reference must be realistic and achievable- both in terms of requirements and deadlines. Here it is important to listen to the opinion of the vendor, since he knows exactly how much time it will take for a particular task. Believe me, it is not profitable for a developer to play for time and wind up the deadline - it is beneficial for him to complete as many projects as possible and do it well so as not to get a blow to his reputation. As for realism, avoiding requests to finish CRM to the level of a collider control system is simple: you should include in the requirements what is really needed at the moment and in the foreseeable future.

For example, RegionSoft CRM is a desktop program, we don't have a browser client. Asking us to create a web application for one company is pointless, this is a major development, it is currently underway and is not a possible refinement for one company. No, of course, everything has its price, but again - in the general case, the requirement is impossible.

It should not be confused with the situation when it comes to custom development and the idea and logic of the application changes radically, in fact, the creation of new software “for oneself” is sponsored. But that's another story.

The specification must be detailed. It is necessary to indicate all the significant details of the future project: from the frequency of using the program to wishes for the interface. The more detailed the requirements are, the easier and faster the implementation and testing will be. It is especially worth paying attention to details if you work in a specific industry (medicine, insurance, banks) - a detailed presentation of the nuances of the interaction between the business and the program will ensure that the vendor understands the task and quickly adapts the system to your company.

Be sure to pay attention to number formats, field names, the presence or absence of drop-down lists, the behavior of buttons and hints, and data types. If the customer uses his own formulas that need to be included in the CRM logic ( for example, the calculation of dealer bonuses), these formulas must be written with a full explanation of their designations and calculation logic.

Yes, corporate software looks something like this, and there are a lot of important little things in it.

The terms of reference must be unambiguous and precise. Vague wording, implementation options, fuzzy requirements - all this is a path to a dead end. It happens that a client, out of good intentions, writes in the TOR several options for the behavior of the system, which are close, but not equivalent. In this case, he is sure that he helps, prompts the programmer, but in fact, the road to hell is paved with good intentions; the developer must understand what exactly is needed, and how to do it, he will choose himself, based on the features of the system and the stack of technologies used.

This year you can make one wish again. Just please don't waste it on something that even I can't fulfill, like clear business requirements!

The terms of reference must be written in human language. And this is important, no, IMPORTANT. I will single out two situations when problems with the language lead to a delay in the implementation of the project.

1. The client tries to demonstrate his technical literacy and fences constructions like: “implement a window with a hint in the body of the calendar with the ability to react to an event call ...” instead of “a window should pop up in the calendar in which you can mark the task as completed”. If you or your internal expert do not have the skills to write technical texts, do not google - write in ordinary words, we understand them.

   The terms of reference should not be a complaint book. We need to solve the problem, not describe it, paying attention to fonts and forgetting about the description of the requirements. The TOR should contain not only the problem itself, but also its solution at the level of understanding - then the developer will already solve it at the code level. Compare “the sales department plans poorly, loses numbers, we have been fighting for a year” And “it is necessary to create a report that will save the values ​​of the plan and the fact of sales on a monthly basis, in the context of product groups”.

   The terms of reference should be able to look to the future. Well, not exactly it, but the people behind it. If it is known that changes in business processes will soon take place, this must be taken into account in order not to pay for revision twice.

   Terms of reference should not be bureaucratic. If you have ever drafted this document, you must have felt how hard it is to avoid the temptation to slip into bureaucracy, to add introductory words, strict turns and describe each item as an article of the Criminal Code (preferably with punishment for everyone for violation). Bureaucratic wording masks an incomplete understanding of the goals of creating TK. The responsibility of the vendor is spelled out in the contract, the budget is also written there. You should not transfer these points to the technical task.

   The terms of reference must be the terms of reference. It sounds paradoxical, but often instead of technical specifications we read letters, complaints, contracts, newly written instructions for CRM or meeting minutes. Of course, it is impossible to work on such a document. In order not to get away from form and content, use the old school trick: look at the term word by word. Technical means that it dictates refinement, technique, is aimed at solving the problem by changing the software. That's the task in the context of software and you need to talk. A task means posing a question, a problem, without advice, hints and preliminary estimates. Just a statement of the problem.

   The commandments are over, now the rebuke

   In addition to the above rules, there are a few more things that are worth talking about. We are talking about goals, plans and expectations - all those leaving that make the project successful, and the relationship between the vendor and the client is almost friendly.

   Terms of reference need to be written quickly, even if you are faced with the task of automating the processes of a mobile operator or a large hypermarket. This is due to the fact that technologies are developing at a tremendous speed, and even the system that you are implementing can survive a major release (and sometimes two) in six months or a year, get new functionality. It may be necessary to reconsider the need for improvements and start the process again.

   

   
   Finally, he found time to finish the TK. But, alas, there are no developers left around to implement it.

   The client is unaware of the stack and technical limitations. And he should not know - this is the task of the vendor, it is he who evaluates the work after drawing up the terms of reference. The customer should not delve into the technology and ask each comma if the vendor can do this or that thing. Draw up a comprehensive TOR and the developer will choose the appropriate architecture - often even better than you might think.

   Estimate your budget and avoid unpleasant surprises- almost the number one joint task. You should not pull the vendor and demand from him an approximate assessment of the work (well, at least approximately, offhand, by eye, but like others, well, in projects of this type, but from experience, well, well, within the margin of error). A full budget estimate is possible only after reading, analysis and final approval of the terms of reference. If your developer does otherwise, get ready for the fact that the revision will cost at least twice as much.

   Proceed from the objective need for changes and expansions- I wrote above that the developer does not disappear and is ready to make changes and additions according to your requirements at any time. Therefore, do not try to create CRM / ERP dreams right away, do not demand from the vendor the “Everything works while I drink coffee” button - work in the system, identify critical comments for you and start collecting requirements and drawing up technical specifications.

   You can write endlessly about technical tasks, this is a real generator of not only memes and tales, but also a headache. You can talk about priorities and design rules, about GOST 1989, which makes the TK inhuman, about the IEEE standards, which are a little better, about prototypes and TK that complement them. But in the end, I would like to limit myself to one, the most important rule: the terms of reference are not a rule of law, not GOST and not a dogma, therefore, if you can improve - improve, you can simplify - simplify, you can do it gracefully and so that everyone likes it - do it. I am sure that after this no one will poke their nose into the TK and say that this is not written there. Or almost no one.

   Throughout December, we give discounts for RegionSoft CRM and all software of our own development. From December 1 to December 15 - 15% and cool installment and rental conditions. We do not have -70% and -90%, because we keep an economically justified price for licenses, and do not take it from the ceiling.

   Well, if you need a CRM system (with or without modification), then go to our website, there is a lot about CRM, its benefits and other corporate software.

   And yes, we are always looking for partners who are ready to sell CRM and other products, improve and sell CRM, sell software and train users. The division of income is fair and beneficial to the partner. Show, tell, teach. Write to [email protected]

   Slides, slides. Comics taken from http://www.modernanalyst.com/ and from Pinterest. If there is a better translation, we will be happy to include it in the post.

Many are faced with the fact that it is quite difficult to explain briefly and clearly what we want in everyday life. And when you need to give a task to a specialist to write a program for an organization or individual entrepreneur, taking into account the features and your own wishes for functionality, then you can generally “hang”.

Who should write the TOR?

Of course, the terms of reference must be provided by the customer, because he certainly knows his needs and capabilities. But, as practice shows, the vast majority of customers are not competent in the field of 1C. That is why the performer himself is often forced to delve into the needs of the customer, understand what final product he needs, and accordingly arrange all this in writing for the programmer.

Why is a specification needed?

In an ideal situation, with one or another refinement in the 1C software product, a technical task is necessary. First of all, the tasks, deadlines and method of execution should be spelled out.

This is an important document, because in the event of any controversial issues, the competent development of terms of reference will be the starting point in negotiations.

To draw up a technical specification or not - everyone decides for himself, but this will definitely not be superfluous: it will simplify communication with the client and give the work a businesslike and concrete character.



Let's designate a list of the most important items that should be in the terms of reference:

1. Purpose / Task. Formulate what should be implemented in the end.

2. Description. Briefly describe the content of the planned improvements.

3. Method of implementation. Describe in detail the methods by which the goal is to be achieved. It is necessary to register all the features of the task in the programming language: registers, directories (create or edit them); interface design, etc. For those who are unfamiliar and have only heard something about a specific programmer language, we advise you not to make unnecessary attempts to “speak” in a technical language. Because Ideally, a description is a dry statement that excludes ambiguity and the possibility of unnecessary questions. In addition, this paragraph may include an example of how such programming has already been done somewhere.

4. Evaluation of work. This item is very important - it needs to describe labor costs.

Two more important points: there are approved standards for writing technical specifications - GOSTs. They are rarely used now, but some clients may ask to use them in the old fashioned way.

And secondly, when the work is handed over, such a thing may arise - “but we kind of asked you to do this and that then ...”. There is a chance that you will have to start doing everything from the very beginning.

Therefore, we repeat that a well-written TOR will be useful for both the customer and the contractor.

Example of TOR for a programmer

Terms of reference 1C for the revision of external processing


Target
It is necessary to set up uploading data from 1C to the bank's AWP.


Description

In connection with the transition of the organization to the configuration 1C “Salary and personnel of a state institution”, it is required to develop other processing that would carry out similar functionality on the new configuration.

Uploading data should be based on the documents "Application for Opening Personal Accounts of Employees" and "Statement for Paying Salaries to the Bank".


Initial data

Available processing for the 1C configuration “Salary of a budgetary institution”, which uploads data from the document “Application for Opening Personal Accounts of Employees” and other directories and registers to a DBF file for data exchange with a standard bank AWP.

Processing unloads data into the TAB_N, NAME, SERNUM, PASSCODE, PDAT, PWHR, BIRTHDAY, POSTINDEX, COUNTRY, CITY, STREET, REGION, BUILDING, CORP, FLAT, BPLACE, CITIZEN fields the relevant information from the 1C configuration previously entered in the specified document and other accounting tables. The personnel number, full name of the employee, his passport and address data, birthday and citizenship are uploaded.


Way of implementation

These will be external reports and processing using the extension mechanism, if the current database compatibility parameters and platform capabilities allow it. When changing the database configuration, you should create: directories, documents, registers.


Job evaluation

P 5 working days of the programmer's work are required.