The highest level
of process organization
The highest level of process organization
of process organization
BGERP is a versatile ERP/CRM/BPM system designed with a modular architecture, utilizing Plugins to extend its functionality. Each Plugin has an assigned Owner who is responsible for its development and maintenance. The following section provides an in-depth exploration of BGERP's main capabilities and features.
One of its notable features is the fully customizable set of attributes for contact entities. These attributes include categories, contact information (names, emails, phones, addresses), accounting data (bank accounts, tax identification numbers), and various others.
The administrator has the ability to parameterize a given business process, configuring its states, responsible parties (executors), and associated departments. Users view processes as sequences and can configure filters and sorting options to display specific information. These processes are versatile, enabling the definition and management of various operations like sales processes, mass email distribution, and subscriber onboarding within CRM/Billing systems. Furthermore, processes can be interconnected and dependent on each other.
BGERP centralizes communication methods by linking email exchanges, phone calls, forum discussions, and HelpDesk messages to specific processes. Each process can have an assigned supervisor who receives notifications for new messages. Additionally, all message exchanges and their histories are stored independently, guaranteeing uninterrupted communication even if the previous supervisor is unavailable.
The Staff Roster Planning module allows for the definition of employee shifts and schedules. Data from this module can be utilized for generating automated timesheets and assigning executors to specific processes.
You might recognize this scenario: after closing a significant deal and receiving payment, the contractor loses interest in fulfilling their obligations. o make matters worse, a complex and unresponsive technical support process creates a communication hell for the Client, replacing live connection to the previously attentive salespeople. This situation might bring to mind experiences with specific car dealerships or software companies.
For a considerable time, the IT industry has grappled with this issue, a challenge now commonly tackled through a concept called Software as a Service (SaaS). Essentially, SaaS replaces a hefty upfront software investment with smaller, periodic payments. These payments can vary based on the services or features utilized, with a flexible selection process. This shift fundamentally transforms the dynamics of Client and supplier collaboration, nurturing a sincere, enduring, and mutually advantageous partnership.
BGERP SaaS solution offers several advantages compared to the traditional software sales approach:
BGERP SaaS scheme also proves convenient for experienced and reliable independent software developers:
The Open Source Code system is sometimes misconstrued as being completely "free." However, this movement originates from the desire to foster collaboration on a fully voluntary basis, without any coercion.
Modern computer programs are highly intricate, serving pivotal roles in various sectors like infrastructure services, manufacturing, and healthcare. Proprietary software companies often capitalize on the complexity and importance of their systems to maximize profits. Consequently, customers (including businesses, governments, and non-commercial organizations) often find it exceedingly challenging to escape this vendor lock-in and switch to an alternative database, ERP, operating or billing system.
Similar dependencies between organizations and software developers also emerge during the process of 'custom development.' This scenario is further complicated by the fact that custom development is an expensive untertaking since the software is specifically tailored for a single client. Consequently, both the software developer and the organization are dissatisfied with the price – it may be too low for the developer and too high for the organization, disregarding the "voluntary basis" principle. As a result, due to limited resources, such custom solutions are often delivered half-baked, lacking proper documentation and testing. Moreover, the software product's lifespan is frequently limited to the tenure of the original developer or employee who created the product.
The challenges mentioned earlier have been effectively addressed resolved by a 'silver bullet,' which is an open-source code. This approach enables anyone to contribute to the development of the open-source product, implement enhancements, and provide diverse solutions based on it. Consequently, users have the liberty to select the most appropriate version or variant. Furthermore, collaboration between developers/product creators and users remains active only as long as it satisfies both parties. This equilibrium ensures that the development process remains adaptable and responsive to user requirements.
Every part of BGERP has its own owner, a developer who receives all complaints and suggestions through a Сonsultant. This innovative approach addresses one of the known drawbacks of open-source projects, which is the lack of developer responsibility for specific code, features, or the product itself. With BGERP's plugin owners having a vested interest in selling subscriptions and generating revenue from the sale of a given subscription, there is a clear incentive to maintain and enhance the system.
Lastly, but certainly not least, in any cataclysm of any scale, whether it be a commercial failure or a geopolitical issue, open-source programs like BGERP will always remain available to their users, much like the Pythagorean theorem.
BGERP follows the Continuous Delivery (CD) software development model, striking an optimal balance between product stability and development agility. This ensures a steady pace of delivering new features and modules to our clients. Major version changes are infrequent and typically occur only when a new feature or modification affects backward compatibility. The current major version is denoted by the value: 3.0 The example in the figure below illustrates a product release cycle.
Stable Releases are published every few months, once the product accumulates several meaningful Changes. For instance, on the figure, examples of Stable Releases are 3.0.1234 and 3.0.2501, their numbers are not mandatory incremented by one. Please note that the figure shows only two changes between Stable Releases for illustrative purposes, whereas in reality, the number of changes will be higher. Each Stable Release undergoes a rigorous automated testing procedure, actually ensuring its stability. Moreover, the development methodology takes into account configuration, API, and DB schema backward compatibility.
Occasional rare errors that managed to occur in the current Stable Release are identified and rectified in the same release. Users can verify the build date of their installed Stable Release and cross-reference it with the date published on the official website. If a newer release is available, users have the option to manually initiate an update to ensure they have the latest version.
We strongly recommend that every client upgrades to the current Stable Release, even those clients who believe "everything is working well, thank you." Why? Firstly, this allows clients to receive fresh defect and vulnerability fixes. Secondly, clients benefit from new features and improvements to existing ones. The actual Stable Release (3.0.2409) is available on our website's front page, and you can find the accompanying changelog here. Additionally, you can always seek recommendations from your assigned Consultant, who can provide an overview of all the new features and improvements found in the new Stable Release.
A change is a code modification identified by a unique number (23456 and 23422 in the Figure), which can involve either a 'fix' for a defect or a 'feature' addition. While Stable Release numbers must be sequential, Change numbers do not necessarily follow this pattern, as different developers can work on the development of several changes in any order. It is also possible for multiple changes to be developed simultaneously. Each code modification within a change is accompanied by a release, as shown in 3.0.1234.23456 and 3.0.1234.23422 in the Figure. These releases containing changes are published in the the catalogue.
Updating to a "Change" build allows clients to quickly integrate new functionality into their BGERP installation. Such updates can be performed by navigating to Administration / App / App status interface snap-in and using Update on change item. This procedure is typically used by change requestors (clients who have requested a specific feature or fix).
Documented changes that have undergone unit or limited integration testing are accepted into the product as part of a Master Release. This release is used for:
The latest item means that updating to any "Change" build inherently acquiring all the features of a Master Release, effectively adding that specific change to it.
BGERP was originally crafted as a CRM and project management solution for a large Internet Service Provider (ISP). Even a moderately sized ISP represents a sizable entity, catering to tens of thousands of users, each associated with numerous processes. Larger ISPs might serve hundreds of thousands or even millions of users. Consequently, our product was designed with the scalability and demands of such extensive organizations in consideration. With time, it has been effectively employed by these entities, showcasing its capability to manage thousands of employees and tens of millions of processes
We don't just jump on the latest tech bandwagon without careful consideration. We don't follow trends for the sake of it. Instead, we meticulously study new industry developments. We observe these trends in our side projects, engaging in deep discussions to understand them fully. We evaluate how these technologies fit into our current setup and future plans. We weigh the pros and cons, thinking about implementation costs, ensuring we make thoughtful decisions.
The evaluation of implementation costs encompasses not only factors like developer (re)training, code, and documentation changes but, more importantly, the updating of products currently deployed at our clients and providing the necessary training to their personnel. We also carefully evaluate risks associated with updating installations, converting database schemes (if applicable), and create comprehensive plans for potential roll-back scenarios and data/code backups.
We recognize that every organization is unique, with distinct processes, organizational structures, and other traits that provide competitive advantages.
In light of this, we have always envisioned and developed BGERP as a platform, not merely a product. This philosophy is evident in the numerous customization possibilities, JEXL scripts, custom code, and open HTTP APIs. The core capability of the BGERP platform is independent plugin development based on a transparent open-source development model, which strikes an optimal balance between Commercial-Off-The-Shelf (COTS) and bespoke solutions. Whenever we introduce changes to the platform, we ensure that up-to-date and comprehensive documentation accompanies them.
BGERP incorporates an embedded authentication and authorization subsystem that meticulously controls and logs every action performed by a platform user. Administrators can configure granular access rights using groups, action lists, and individual permissions.
In our team, we rely on our very own BGERP to streamline our development and client relationship management (CRM) processes. We utilize the latest builds in our day-to-day activities, adding an extra layer of testing. Our developers, who use our BGERP system themselves, actively participate by proposing new features and suggesting UI improvements.
While our team was working on a BGBilling product, we quickly realized the need for a platform that could support our rapidly growing client base by organizing various critical business processes, such as subscribers' onboarding and offboarding, technical support, and managing debtors and late payments.
To address this requirement temporarily, we developed a small BGBilling plugin called CRM. It served as a simple solution, enabling us to set up and track customer requests effectively. However, the CRM plugin had its limitations:
Despite exploring numerous solutions available, none of them fully met our clients' needs in our opinion. We identified several gaps with the existing solutions:
These observations led us to the conclusion that we needed to develop a more comprehensive and tailored solution to effectively meet our clients' requirements.
Invoice printing form
Report round chart
Report bar chart
Backup
App Status
Process queue
