Specialized software: Buy or write?
Greetings to the Khabrovites!
I think many have faced the problem of choosing software for any specific tasks. Unlike the dominance of all kinds of editors or clients for social networks (Facebook, VKontakte, etc.), it is extremely difficult to select a highly specialized program. Such software is a niche product, respectively, the manufacturers of such software are small and the community has little interest in such programs (there are no manuals, reviews, or other useful information on the network) - you have to move by touch.
This is where the agony of choice comes - to take the finished "pig in a poke" or to shoulder the burden of developing software "for your beloved."
I wasnot lucky to go both ways ...
I began my work in the company -buy-sell distributor. We bought large quantities of household chemicals and cosmetics from different manufacturers and sold with delivery to a large number of large and small stores. In addition to a warehouse and a dozen cars, the company worked a bunch of small sales representatives who traveled to customers and collected orders. I wanted to optimize this part of the work.
The fact is that from morning to night each sales agent collected orders (simply wrote them down on a piece of paper), and in the evening he returned to the office and dictated these applications to operators who drove them into the database (1C). All this took a lot of time - I had to collect and load the ordered goods into cars all night.
I started looking for a solution. It immediately became clear that there were extra operators in this scheme. If sales representatives (or customers) directly entered orders into the database, bypassing paper media, and even in real time - it would be just super. Such solutions have already been on the market - these are special programs running on PDAs with the ability to exchange via GPRS / WiFi. From a not very large number of proposals, I chose a solution from a company that was at that time the industry leader. Immediately I bought a couple of PDAs and began to experiment. Everything worked, far from “half a kick”, but still orders began to come directly to the database during the day - and as a result, we refused operators and night shifts in the warehouse, without losing the speed of delivery of goods to customers.
Only the fact that the software itself was not very convenient overshadowed. And all due to the fact that the developers with each release contributed more and more functions that were often poorly thought out, and sometimes frankly superfluous. The program began to resemble some kind of clumsy monster. Working with it is like using Photoshop to view photos ... For
two years I endured - or rather, not even me, but the sales representatives - I caught them from time to time when they sit in the evening and cut applications from good old pieces of paper to new fashionable PDAs. And I decided to write a custom solution to fit my needs. I found a developer company, made up the statement of work and put it into production.
What did I want to get in this new solution?
A small comparison of key technical points:
After a certain time, the first beta version was ready and I started testing. Despite the fears that testing and catching of “bugs” would be delayed, I soon received a program release and quickly transferred my entire farm to new software, immediately feeling the benefits - the whole system practically did not require any support from me (unlike last decision, where with enviable frequency I had to shaman something somewhere). And most importantly, it has become much more convenient for trading agents to work. Papers disappeared completely, and sales agents became like mobile gamers - they work only on PDAs.
After some time, another company approached me with a request to introduce a similar technology (someone from the leadership of this company saw my sales agents with PDAs "in the fields" and became very interested). I tried and this experience was so successful that I continued to develop the product with the developer.
Please love and favor: http://www.imta.com.ua As a conclusion:
Do not be afraid to reinvent the wheel. Believe me, no one knows your needs better than you, and faith in the “smart uncle” who will come up with everything for you is unlikely to bring you the desired result. And having spent a little of your own efforts, you can get not only a working solution, but also some other “goodies”. On the other hand, do not forget that developing your own product is not always cost-effective and requires a lot of attention and efforts to support and develop - it is up to you to decide how to proceed in each particular case.
Good luck!
PS This article was written not only by me. When I was still living in Kiev, I worked in a very comfortable company IMESC. One of the projects I worked on was IMTA. I still have the best reviews about the team and partners of the company, and when one of the initiators of this project (Alexei Plutenko) invited me to publish an article, I gladly agreed.
I think many have faced the problem of choosing software for any specific tasks. Unlike the dominance of all kinds of editors or clients for social networks (Facebook, VKontakte, etc.), it is extremely difficult to select a highly specialized program. Such software is a niche product, respectively, the manufacturers of such software are small and the community has little interest in such programs (there are no manuals, reviews, or other useful information on the network) - you have to move by touch.
This is where the agony of choice comes - to take the finished "pig in a poke" or to shoulder the burden of developing software "for your beloved."
I was
I began my work in the company -
The fact is that from morning to night each sales agent collected orders (simply wrote them down on a piece of paper), and in the evening he returned to the office and dictated these applications to operators who drove them into the database (1C). All this took a lot of time - I had to collect and load the ordered goods into cars all night.
I started looking for a solution. It immediately became clear that there were extra operators in this scheme. If sales representatives (or customers) directly entered orders into the database, bypassing paper media, and even in real time - it would be just super. Such solutions have already been on the market - these are special programs running on PDAs with the ability to exchange via GPRS / WiFi. From a not very large number of proposals, I chose a solution from a company that was at that time the industry leader. Immediately I bought a couple of PDAs and began to experiment. Everything worked, far from “half a kick”, but still orders began to come directly to the database during the day - and as a result, we refused operators and night shifts in the warehouse, without losing the speed of delivery of goods to customers.
Only the fact that the software itself was not very convenient overshadowed. And all due to the fact that the developers with each release contributed more and more functions that were often poorly thought out, and sometimes frankly superfluous. The program began to resemble some kind of clumsy monster. Working with it is like using Photoshop to view photos ... For
two years I endured - or rather, not even me, but the sales representatives - I caught them from time to time when they sit in the evening and cut applications from good old pieces of paper to new fashionable PDAs. And I decided to write a custom solution to fit my needs. I found a developer company, made up the statement of work and put it into production.
What did I want to get in this new solution?
- Firstly, I didn’t like the way I implemented the current product in my accounting system. There were difficulties with the fact that the data structure that PDA clients exchanged with the database (1C) was poorly thought out, unnecessarily complicated and confusing. In addition to organizing the exchange, it was necessary to “raise” a bunch of additional subsystems: a separate server with a white IP; A service that receives data using an undescribed protocol Message Queue service a couple of plug-ins (external components) for 1C and at the same time, the exchange took place using simple files "shared" over the network: D. That is, I needed a program that was as simple as possible in integration with other systems - without unnecessary links and third-party components.
- Secondly, an interface about the problems with which I already wrote above. The new program should definitely be easy to use.
- Thirdly, the program should contain only the functionality I need, without frills that no one needs, but only complicate the work.
- And of course there were a lot of little things that I wanted to do better.
A small comparison of key technical points:
| Third party solution | Own decision | |
|---|---|---|
| The process of sharing with the database | Direct TCP / IP communication between the PDA and the "office server". A special service listens to the TCP port, receives and decomposes data into file system directories, and “pulls” 1C through Message Queue and a special dll, and 1C, in turn, downloads data from files using another dll. | The PDA leaves data on the ftp server, and 1C takes data from this server with just one COM object. |
| Usability | In view of redundant functionality, the interface is overloaded with all kinds of checkmarks, lists and unnecessary confirmations. The most frequently requested actions are done in a few touches. | Simplified access to the main functions (creating an application, choosing a client, navigation through the list of goods). It’s much more convenient to enter the quantity (the “longest” process at work) - you can use a calculator, a hard keyboard or a joystick to enter (mega convenient: rocked to the right - added a box / little thing, rocked to the left - diminished ...), or you can just “click” number with your finger or stylus. |
After a certain time, the first beta version was ready and I started testing. Despite the fears that testing and catching of “bugs” would be delayed, I soon received a program release and quickly transferred my entire farm to new software, immediately feeling the benefits - the whole system practically did not require any support from me (unlike last decision, where with enviable frequency I had to shaman something somewhere). And most importantly, it has become much more convenient for trading agents to work. Papers disappeared completely, and sales agents became like mobile gamers - they work only on PDAs.
After some time, another company approached me with a request to introduce a similar technology (someone from the leadership of this company saw my sales agents with PDAs "in the fields" and became very interested). I tried and this experience was so successful that I continued to develop the product with the developer.
Please love and favor: http://www.imta.com.ua As a conclusion:
Do not be afraid to reinvent the wheel. Believe me, no one knows your needs better than you, and faith in the “smart uncle” who will come up with everything for you is unlikely to bring you the desired result. And having spent a little of your own efforts, you can get not only a working solution, but also some other “goodies”. On the other hand, do not forget that developing your own product is not always cost-effective and requires a lot of attention and efforts to support and develop - it is up to you to decide how to proceed in each particular case.
Good luck!
PS This article was written not only by me. When I was still living in Kiev, I worked in a very comfortable company IMESC. One of the projects I worked on was IMTA. I still have the best reviews about the team and partners of the company, and when one of the initiators of this project (Alexei Plutenko) invited me to publish an article, I gladly agreed.