Oproep tot kandidatuurstelling (aangepast op )

Oproep tot kandidatuurstelling (aangepast op 23.08.2013) Overheidsopdracht met betrekking tot de implementatie van een enterprise transactioneel systeem Onderhandelingsprocedure met voorafgaande bekendmaking

BXL 1434 – 26.07.2013

BTC, Belgian development agency

1/33

I. VOORWERP VAN DE OPDRACHT I. 1. Aanbestedende dienst De aanbestedende dienst van deze overheidsopdracht is de “Belgische Technische Coöperatie”, naamloze vennootschap van publiek recht met sociaal oogmerk, met maatschappelijke zetel in de Hoogstraat 147, 1000 Brussel (ondernemingsnummer 0264.814.354, RPR Brussel). In toepassing van de wet van 21 december 1998 tot oprichting van de ‘Belgische Technische Coöperatie’, heeft BTC de exclusieve bevoegdheid inzake de tenuitvoerlegging, binnen of buiten het grondgebied van België, van taken van openbare dienst op het vlak van de directe bilaterale samenwerking met de partnerlanden. Op verzoek van instellingen van openbaar nut kan BTC bovendien ook andere opdrachten inzake ontwikkelingssamenwerking uitvoeren en eigen acties ontwikkelen die bijdragen tot de realisatie van zijn doelstellingen. BTC stelt zijn middelen en zijn expertise ter beschikking om de armoede in de wereld uit te roeien. Het agentschap sluit zich aan bij de inspanningen van de internationale gemeenschap en wil een samenleving tot stand brengen die de huidige en toekomstige generaties alle mogelijkheden biedt om te bouwen aan een duurzame en rechtvaardige wereld. De medewerkers in Brussel en in het buitenland vertolken het engagement van de Belgische staat en van andere ontwikkelingspartners voor internationale solidariteit. Enkele kerncijfers : 

200 ontwikkelingsprojecten in 18 partnerlanden (Afrika, Azië en Zuid-Amerika)



1.400 medewerkers



1 hoofdkantoor, 18 vertegenwoordigingen (representaties), 100+ projectkantoren of sites



229 miljoen EUR omzet



49% van de activiteiten uitgevoerd in fragiele staten



52% van de bestedingen in Centraal-Afrika

Meer informatie over BTC is te vinden op de website www.btcctb.org.


2/33

I.2 Voorwerp van deze opdracht BTC wil de 200 projecten, 18 vertegenwoordigingen en de hoofdzetel voorzien van een geïntegreerd informatiesysteem, dat de volgende componenten bevat : 

Een enterprise transactioneel systeem



Een project management systeem (of als onderdeel van het enterprise transactioneel systeem, zie hieronder)



Een document management systeem



Een samenwerkingsplatform (collaborative platform)



Een Business Intelligence (BI) systeem

Zoals verder beschreven zijn deze componenten geen losstaande, maar nauw verbonden en sterk geïntegreerde toepassingen. Deze overheidsopdracht beperkt zich tot het enterprise transactioneel systeem, eventueel aangevuld met een project management systeem (indien dit deel uitmaakt van het softwarepakket dat wordt aangeboden). Het enterprise transactioneel systeem voorziet volgende modules, die verder in dit document in detail worden toegelicht : 1. Human resources management 2. Financial management 3. Purchasing 4. Logistics 5. Relationship management 6. Project management Deze overheidsopdracht bevat één vaste schijf en 6 voorwaardelijke schijven. De vaste schijf omvat twee onderdelen : de uitwerking van een prototype en een eerste implementatiefase. Bij de uitwerking van het prototype wordt eerst een globaal ontwerp van het toekomstige enterprise transactioneel systeem gemaakt (volledige scope). Dit ontwerp wordt omgezet naar een eerste testversie van het systeem (het prototype), dat de belangrijkste componenten en een aantal testgegevens

bevat,

maar

niet

alle

processen

en

functionaliteiten

voorziet,

noch

alle

kwaliteitsvereisten. De bedoeling is om, in een relatief beperkte tijdsspanne en zonder zware investeringen, 

een zicht te krijgen op de basiswerking van het systeem


3/33



de haalbaarheid van het implementatieproject te evalueren



buy-in van een aantal key users te creëren

Na het prototype gaat de eerste implementatiefase van start, die de volgende submodules binnen de module HR management omvat, van design tot en met de roll-out (inclusief data migratie) : 

HR Master Data (HR-01)



HR Recruitment and Selection (HR-03)



HR Contract (HR-04)



HR Payroll (HR-05) : het gaat om voorbereiding van de salarisberekeningen, geen interfacing met sociaal secretariaat of externe systemen in deze fase



HR Availability management and calendars (HR-06)



HR Time sheet (HR-07)



HR Training (HR-08)

De voorwaardelijke schijven bevatten alle andere submodules die niet in de vaste schijf zijn opgenomen : 1. Human resources management : de 2 submodules die niet in de vaste schijf zijn opgenomen 2. Financial management (9 submodules) 3. Purchasing (7 submodules) 4. Logistics (3 submodules) 5. Relationship management (3 submodules) 6. Optioneel : Project management (10 submodules) BTC houdt zich het recht voor om de voorwaardelijke schijven niet te bestellen, zonder recht op enige schadevergoeding. Het voorwerp van deze opdracht wordt hieronder verder in detail toegelicht – in het Engels, gezien de technische specificiteit – met de beschrijving van 

De algemene werkingsprincipes van het nieuwe informatiesysteem (cf. “I.2.1 General operating principles”).



De toekomstige software architectuur (cf. “I.2.2 Applications architecture”) .



De mogelijke scenarios (cf. “I.2.3 Scenarios”).



De technische context (cf. “I.2.4 Technical context”).


4/33

I.2.1 General operating principles The operating principles laid out below are no technical prescriptions but describe the end objective of the future IT environment. The end objective is not just to have a system. The end objective is to structurally improve the day-to-day operation of BTC as a whole, in order to allow BTC to achieve its strategic objectives. The work to date shows that those improvements can be by linking the different, interacting levels and departments of BTC. The systems, embedded in redesigned and simplified processes, will be the glue that hold it together. We need to make sure that all stakeholders recognize that this major change is needed to not only improve operations, but to ensure BTC’s viability over the longer term.

Local empowerment BTC’s interventions will be provided with (a) system(s) that will allow them to manage their project in all its functional domains. These system(s) will generate reporting information which will support decision-making by the intervention, but will also allow for monitoring at other levels of the organization (representation, head office), respecting the role of each of these levels.

Management by exception To avoid administrative overhead in writing many open ended reports and in order to really detect the important issues, the main reporting information should be based on management by exception (hereafter: MBE) techniques. The system should support establishing (parameterization of) a set of exception levels. If an event, an occurrence, a transaction or a risk goes beyond such a set level, a warning is triggered and the responsible user is focused on dealing with that exception. Of course, the trigger levels depend on the nature, the size and/or the operating mode of a project (own management, co-management or national execution). Those exception levels will be at incident level for the project level and will be at higher accumulated abstraction levels for representation, country team and HQ.

Based on transactional data In order to support the processes, the system (which registers transactions, hence is transactional) will collect, produce and store relevant information at the detailed incident level. This data and information can later be used, reused and/or analysed. This way, we avoid administrative overhead incurred when creating unique, open ended reports because they will be replaced by standardized reports that are (partially) automatically generated based on the available information gathered at the project level. The data has a second use other than reporting as well. It will feed the exception reports mentioned in


5/33

the previous paragraphs. It is important to notice that data is generated at project level, representation level and HQ. Consequently, these data, or subsets of these data, must be shared and be unique in order to ensure correct, timely and appropriate information management.

Audit trace All transactions are user traced and time stamped to allow for subsequent audits when needed. All entries and modifications that are executed by any user, including the uniquely defined administrators are logged and linked to the transaction identification with a time stamp. Even when warnings are issued and the user decides to continue without immediately dealing with the specific warning (which can be motivated if an operational need would arise), a detailed trace of the operation is recorded. This allows the user to go back later and clear any pending warnings.

Security and authorization Every user belongs to a specific security and authorization profile granting it access to specific modules or data corresponding to the profile’s needs and mandates, linked with the function descriptions. User groups are not restricted to staff members only : specific and limited access profiles can be created for external stakeholders (e.g. partner institutions, consultants, job applicants, etc.), depending on the need for information from or for interaction with the system.


6/33

I.2.2 Applications architecture Based on a thorough analysis of BTC’s processes, bottlenecks, root causes and opportunities for improvement, the TO BE applications architecture of the organisation has been designed. Nine general domains or modules have been identified :

These modules must not be considered as stand-alone entities, but as components that are closely integrated due to the multiple links and interdependencies between them. The TO BE applications architecture has been further detailed to the level of the sub modules :


7/33

The core of BTC’s future IT architecture will integrate data and processes within multiple organisational domains in order to optimize exchange of and access to information, to reduce redundancies and to improve efficiency. These domains are the scope of this public contract (see above) : 

Human resources management



Financial management



Purchasing



Logistics



Relationship management



Project management

Although out of the scope of this public contract, it is important to know that links will be necessary with the three other domains identified above 

Collaborative tools



Document management



Business intelligence

The following subchapters describe the characteristics of each domain, the operating principles, the sub modules, and the links between them.


8/33

Human resources management The HR module(s) must allow BTC to manage its human capital in all its sub-domains, including recruitment & selection, competence management & evaluation, training and payroll. HR Master Data (HR-01) All HR sub-domains are dependent on access to the resource information in a central Human Resources database, which covers the actual, past and possible future human resources at BTC (head office, representations and interventions) : 

Staff (HQ, expat and national staff members)



Interns and students



Candidates



Consultants



Ex-employees

This central database links towards the functions database, the competences database and the training database. HR Function description (HR-02) The central database of function descriptions contains for each function : 

its position within the organisation and its classification



the job description



the responsibilities and mandates linked with the function (e.g. commitments, payments, bank accounts, system authorisation, etc.), so that if resource is linked to a function, the responsibilities and mandates of that function are assigned to that resource.



the competences required for the function (main education/profession, general and technical competences, certifications and skills)

HR Recruitment & Selection (HR-03) The recruitment & selection module relies on the two databases described above : 

The function description database provides information for the job description, the profile and the selection criteria.



The HR Master database forms a pool of possible candidates (actual and former staff members, candidates who have been selected but not recruited, etc.). Filters can be used to look for specific profiles based on competences, experience, etc.

This module supports the complete recruiting and selection cycle from profile definition up to the contract. Standardised CVs and profiles (competences, knowledge, experience) are entered by the


9/33

candidate directly. Non-recruited interesting candidates can be added to a 'selection pool' database for future positions (for a pre-defined period of time). Every step or transaction in the workflow is stamped with user and time data in order to ensure a historic trace of all activity. The BTC/candidates communication records are registered as well. HR Contract (HR-04) The compensation elements in the labour contract, linked to the functions database, are not simple text but are parameters that are actively used in the payroll systems, cost accounting, treasury management and budgeting. The signed contract can be consulted through a link to the document management system. HR Payroll (HR-05) BTC has 20 payrolls : one in every partner country (18), an expat payroll and a HQ staff payroll, each governed by different legislation. The Payroll module supports the preparation of the salary calculations, by retrieving all necessary parameters from the HR Master Database, the HR Contract module and the HR Time sheet module. The relevant parameters are exported or interfaced to external payroll systems, which can be social secretariats, payroll tools, Excel, etc., and which are specific for each country. HR Availability management and calendars (HR-06) The availability of the personnel is managed by having a calendar reflecting the individual time profile (4/5 f.i.) and supporting request management for vacation, missions (assignments), illness, maternity leave, etc. HR Time sheet (HR-07) The time sheets are prefilled with time profile calendar data and the validated leave request data of the person including missions (assignments). HR Training (HR-08) A training module includes all the known and registered training courses, as well as the request workflow and the history of training attendances and evaluations. The module is linked with the HR Master database to track trainings planned and followed per resource, and with the competence management & evaluation module. HR Competence management & evaluation (HR-09) The competence profile originating from the function description database (possibly adapted after the function meeting) is used to support the evaluation process. Specific skills can be evaluated as well and might even become legitimate selection criteria. The module will support BTC’s development circles, which is an important tool for setting objectives, coaching and follow-up. The development circles include planning, performance and assessment meetings between staff members and their supervisor.


10/33

Financial management Budget management - Creation & approval (BM-01) Budget management is managing the complete budget cycle from budget definition, approval and creation to the reservation and consumption of budgets for purchases and to the management of budgets for human resources. The budgets are created based on mark ups of last year budgets or real expenses based on links between cost accounts, project accounts and budget accounts. Budget approval workflows are supporting the validation of the budgets. Budget management - Reservation & follow-up (BM-02) Budget amounts for purchases are first reserved when the need is identified and the procurement process planned, then committed after publication and finally consumed when invoiced (respecting approval workflows). All transactions (reservation, commitment, expense) are related to the relevant budget. The same is true for project budgets that are linked into budgets at a higher level. Project accounting and budget management (or budget accounting) are integrated. The non-project overhead budgets also take part in the analytical distribution of costs (HQ and country office cost centres). In order to ensure budget transparency and efficient monitoring, a top down integrity of data in the budget information is required. The budget figures are accumulated at every (budget)node of the tree structure of the Work Breakdown Structure of projects, programmes and budgets. Treasury management – Forecasting (FT-01) Cash is present throughout a network of bank accounts over the 18 countries concerned. Project planning and planning updates drive cash needs planning. The information from the financial requirements planning, from booked purchase orders and planned payments and from payroll is allowing the system to calculate a reliable cash forecast for the long term, medium term and short term. When time windows are shifting nearer the cash forecast can gradually be reconciled with reality and the actual deposits on the accounts worldwide. Treasury management – Bank account management (FT-02) Due to the extensive amount of bank accounts spread over the 18 countries, the treasury management will need to manage the treasury up to the detailed level of those bank accounts. Treasury management – Payments (FT-03) The payment approval workflow uses the personnel database which is linking to the right mandates of the function description of the concerned persons. A payment proposal is made for all payment approved invoices. The proposal takes all necessary constraints into account. A payment proposal is issued by bank account. Payments are performed with e-banking tools similar to Isabel in Belgium, or by classic bank transfer in most partner countries.


11/33

Financial accounting – General ledger (FIN-01) BTC’s headquarters and country offices apply double-entry accounting (based on Belgian GAAP), while its interventions currently apply cash accounting only. BTC considers to apply double-entry accounting at all levels, so that every unbalanced entry is automatically detected. In order to be able to cope with potential chart of account constraints of the partner organizations and/or partner countries, the accounting system should be able to connect alternative chart of accounts to the common charts with automatic synchronization. Based on the truly international nature of the transactions the multicurrency functionality should cover maximum flexibility and yet be thorough. The currency rate of the document date and the booking date should be logged to allow for multicurrency reconciliation for mixed money transfers and transactions covering regularly multiple currencies for one payment requirement spread in time (when the multiple currencies fluctuate heavily in the meantime, to be booked and reconciled in a sound way). The most extensive multicurrency requirements are clearly required. To allow for a complete integration with the G/L, the projects should be managed in a projects subledger. Project figures can at all times be reconciled with the General Ledger figures. All information relating to budget consumption (not commitment) is based on accounting data (booked figures). Each project has at all times a financial project situation. A project accounting has mainly a cost focus which makes a project journal comparable to a purchase journal. The details of the booked transactions (entered in the field or at HQ) are available at the project account level. Provided the double entry accounting principle is applied, a double balance is continuously maintained. Within financial accounting all accounts at all levels are in debit/credit balance including all projects. Additionally the Financial Accounting (G/L) and the Analytical Accounting are also in balance against each other. Financial accounting – Bank journals (FIN-02) For the extensive amount of bank accounts to be managed over the 18 countries, extensive banking ledger functionality is required in conjunction with treasury management. The bank and cash money transfers (payments and receivables) should automatically be matched, allocated and booked to the originating documents. Financial accounting – Accounts Payable (FIN-03) The payables management of the accounting system including purchase invoice booking and purchase invoice control to set the invoice payment approved. Analytical accounting (ANA-01) Analytical accounting is already very much elaborated in the existing legacy systems. Up to eleven independent analytical dimensions are used for the moment. BTC will continue to use the concept of


12/33

Multi-dimensional cost an Analytical accounting with independent non-hierarchical dimensions going beyond the classical cost driver/cost centre-/cost unit cascade. Additionally cost accounting is highly integrated with other modules: 

Financial accounting: all cost used come from the financial accounting and have also been booked in a P/L or balance account (f.e. amortizations).



Budget management: a budget can be defined as a cost centre



Project accounting: projects are the main analytical dimension



BI data warehouse: analytical information can be combined with other information to create added value intelligence.

Purchasing Purchasing – Vendor management (PUR-01) The basic vendor record is defined in the contacts database of the xRM module (see below). As an extension to this database, additional vendor management features are available: related to pricing, product catalogue, e-procurement, etc. Purchasing – Public procurement (PUR-02) The complete phased purchasing cycle which is typical for public procurement is supported. As BTC procures under Belgian, European, but also partner country legislation, the cycle has to be adapted to the specific number of phases, lead times or requirements of every country. Generic elements including budget reservation, purchase order and execution follow-up after awarding will be handled in the common system. An items database (see items database in logistics: LOG-02) or even an items per vendor database is used to manage reference prices before a purchase is performed. Purchase budget approval and reservation can be done using the reference prices. Procurement has an important impact on the project planning and hence this module has to be linked with the Gantt chart planning board and Critical Path Management. Purchasing – Tender database (PUR-03) All the relevant vendor tenders that have ever been received are registered and can be looked up in an easy way. In this way, access is provided to accumulated knowledge of past purchases in order to speed up procurement. Purchasing – Contracts (PUR-04) The database and management of procurement contracts and execution agreements that are generated after either a public procurement procedure or the elaboration of an execution agreement. Execution agreements and public sourcing purchasing can be handled similarly by including both in


13/33

project templates. Country specific procedural delays can be set up in the templates providing a jumpstart for project planning. Purchasing – Purchase order (PUR-05) All purchases have to be performed through a formal purchase order. Purchase orders can be entered directly or can be converted from requirements messages. The system will prompt to the appropriate contract to perform a call off from. Purchasing – Vendor evaluation (PUR-06) Monitoring the customer service level of every vendor in terms of delivery within specification and according to budget or price (within regulatory limitations). Using vendor evaluation information also through the central vendor database will increase quality of the purchase contracts and agreements. Purchasing – Purchasing / procurement (PUR-07) The procurement/purchasing module manages the system workflow of validation and checks for purchase orders from the request to the reception. The receiving information (specification) is automatically linked to the purchase order. The vendor invoices can directly be validated using the three-way match : 

All purchases have to be performed through a formal purchase order (no emails f.e.)



Every product or service delivery is “received” against specifications and quantity in the purchase order



Upon reception, purchase invoices can be directly checked for being within specification and quantity through the receiving information on the one hand and checked for the correct amount on the other hand.



Only mismatches for specification and quantity or amount are to be approved by the field.

Logistics Logistics - Inventory (LOG-01) Upon reception, material and assets are entered in the inventory. For some types of fixed assets (e.g. IT material), a label with bar code and identifier is printed and tagged on the asset. For every asset, its actual location (and quantities, if applicable) will be known, including “in transit” when goods are moved between location, ensuring the complete traceability of goods. The inventory will also include the project’s archive boxes, which contains the paper documents that need to be archived. Logistics – Price management (LOG-02) An item database with products and services and descriptions is used to manage prices of products and services. These prices are used for budgeting and cost estimation for purchasing.


14/33

Logistics – Warehouse (LOG-03) An item database with products is used to manage inventory and the right on hand inventory at every physical location of all the material that needs to be inventoried including all the paper archives boxes. Supporting physical transactions like receiving, putaway, picking, packing and shipping.

Relationship management Partner relations (RM-01) The partner relations database must allow BTC to keep track of all external partner information. All organizations, be it ministries, partner organizations or vendors, are registered, with the possibility to define their subdivisions and hierarchical relations. Contacts can be defined and linked to other contacts or to organizations by also defining the role in that organization (f.e. board member). Each description or link has a limited life cycle. Therefore every status has a start and end date and is logged for later inquiry. Event management (RM-02) Events can be organized by easily using the contacts and organizations in the partners relations database. The event organization itself is to be compared with tasks management close to small project management. Case management (RM-03) Related to contacts or organizations complaints, claims, litigation or in general cases can be managed and followed up.

Project management As mentioned in the introduction, some important characteristics of BTC interventions are : 

Management for development results : projects are oriented towards achieving short, medium and long term development results and thus changes in people’s lives. Development results vary between countries, sectors and interventions, and can be material (e.g. a school) or immaterial (e.g. better education, less unemployment, etc.).



Projects are managed by BTC and its partners (mainly local Ministries), based on partnership and mutual accountability principles.



Projects and programmes generally have a duration of 4 to 5 years, with total budgets varying from 1 million EUR to 25 million EUR.



Projects are executed in 18 different countries with mostly poor infrastructural contexts, which impacts on possible software configurations (see chapter “Technical context”).



Some BTC interventions are divided into a number of sub-projects, with some project


15/33

elements managed at the central project office, and some at the sub-level. The project management module will be used by the interventions, but will also allow for monitoring at other levels of the organization (representations and head office), respecting the role of each of these levels. The following sub modules have been identified : Project definition database (PM-01) This project definition database will contain all project identification details regarding to scope, responsibilities, validations, official documents. Project WBS set up (PM-02) The project can further be defined into detailed activities by using the stepwise refinement tool of defining a detailed Work Breakdown Structure. At every level of the tree-structure all the project metrics are been summarized for the lower levels. The WBS is linked with the Gantt chart planning board. Project template management (PM-03) By project type, project templates can be used to facilitate the project planning activities. Document templates will be made available per activity. Opening the document template feeds it with contextual metadata and when saved all the right links from the document library are updated automatically, without duplicating the document. When needed a new template can developed by assembling project template partitions into a new type of project template. Multiproject resource planning (PM-04) Human resources can be assigned to more than one project. Resources can be assigned to tasks interactively by having a simultaneous view on the load allocation of every particular resource on every task and the effective remaining capacity (personnel availability included) of the given resource. Preferably, general profile resources can be assigned in a first planning exercise, before the specific individual can be allocated. Gantt chart planning (PM-05) For every project a Gantt chart view is available with manual planning possibilities: moving tasks, adding and viewing predecessors, exception signals, critical path visualisation. Multiple level viewing is possible, allowing a drill down from the highest level to the smallest activity. A baseline planning can be set, in order to allow for tracking of planned versus actual. Risk/quality management (PM-06) Project risks are identified, analysed (probability & impact), treated (actions, who, when) and followed up. Quality indicators can be defined and followed up. Project requirements planning (PM-07) All defined activities are tagged as Make (own activity) or Buy. For the buy activities the system will create purchase messages that can be converted into purchase orders.


16/33

Financial resource planning (PM-08) The project requirements (purchases) and their timing is translated into a cash requirements plan by translating the purchases in cash flow, taking into account payment terms. Critical path management (PM-09) The system first detects the initial critical path and subsequently watches the changes in planned or actual timing to adapt the critical patch when needed. All date changes or delays affecting the critical path create an exception message. Project progress management (PM-10) “Management for development results” (see above) implies that the management of inputs (finances, HR, etc.) and activities are all oriented towards achieving short, medium and long term development results and thus changes in people’s life. Therefore, BTC projects monitor set of indicators that are defined during project design, and continually adapted during implementation. Indicators are captured in a ‘monitoring matrix’. This matrix gives an overview of indicators (vertical yaxis) and their values (baseline value, achieved values at different times, (intermediate) target values) (x-axis). Indicators can be quantitative performance indicators (measurable), but can also be qualitative (less measurable, rather verifiable). For every indicator for which a baseline value and a target value has been identified, a degree of realisation can be generated. Next to a tool to centralise data on indicators, the monitoring matrix is also intended to centralise technical details about the indicators as such: the indicator protocol. This includes information on: how is an indicator measured, drawing from what information/data source, the unit of measurement, startend

of

measurements,

frequency

of

measurement,

person

responsible

for

data

collection/measurement, cost of measuring indicator, etc. Results monitoring, but also timing and budget follow-up, adheres to the principle of “manage by exception” (see general operating principles). The exception messages should occur if a change has an impact on the critical path (hence influence timing), if it impacts budget (Estimate At Completion), if development results are not (sufficiently) reached, if critical risks are identified, if decisions of the project’s steering committee are not followed up, etc. When an exception is detected the cause can be analysed using a drill down to the detailed level.

The project management module has a number of interdependencies with other modules : 

Human resources : resource planning depends on the definition of the resources in the HR domain, and the availability of these resources.



Finance : project metrics are in line with the financial, budget and analytical accounting. In the Work Break Down structure every level contains the summary of the most recent information of the levels below for all the defined metrics: ( budget, committed, consumed, Estimate to


17/33

Complete etc…), although flexibility is needed for the level on which the financial metrics will be defined or followed up (e.g. budget on results level instead of activity level). 

Purchasing : the planning of the sourcing requirements are to be included in project management. The purchase order becomes a virtual part of the project with its delivery date and cost.



Collaborative : each project can directly be accessed and managed by logging into the right project workspace of the collaborative tool.



Document management : all necessary forms, drawings, documents are linked to the related activity in the project. Document templates can be opened starting from the activity and the resulting document will be linked to this activity (link with document library).


18/33

I.2.3 Scenarios As mentioned in the previous chapter, the modules of the TO BE applications architecture must not be considered as stand-alone entities, but as components that are closely integrated due to the multiple links and interdependencies between them.

BTC assumes that 

one single system will not respond to all needs described above ;



the future architecture will consist of a combination of systems that cover 1 or more modules and that will need to be integrated with each other ;



multiple scenarios exist for these combinations.

For the 6 modules in this public contract, BTC identifies different scenarios : 

Scenario 1 : all 6 domains are covered by the same transactional system, used at all levels of the organisation.



Scenario 2 : HR, Finance, Purchasing, Logistics and Relationships are covered by the same transactional system, used at all levels of the organisation. Project management, however, due to its importance for BTC and the specific requirements described above, is covered by a dedicated system, which is integrated with the transactional system.


19/33



Scenario 3 : due to the quality issues of internet connections in our partner countries (see chapter “Technical context”), a separate system for the project level is needed, which includes project management, but also project HR, project finance, project purchasing & logistics. The data from this offline system could be synchronised periodically (when a connection is available) with the central transactional system.

Other scenarios are not excluded : respondents are free to propose other scenarios that might be better-suited for BTC’s situation.


20/33

I.2.4 Technical context The applications architecture described in the previous chapter applies to all levels of the organisation. This implies that most modules, or subsets thereof, will also be implemented in the field (18 countries) where Internet connectivity is of variable quality. Special attention is to be drawn to this particular constraint. Indicative Internet link speeds and quality The data hereunder reflect the actual situation. 

Head office (Brussels) : 20 MBs, excellent quality



18 representations : 512 kbps to 1024 kbps, good quality



Projects/programmes : 64 kbps to 256 kbps, variable quality

Variable quality can mean: no connection during some hours, intermittent connection, big latency times, changing transmission speed, etc.

Application configurations for the projects: constraints and possible solutions It can be assumed that at HQ Brussels 20 MBs throughput is available in a reliable manner, at the representation level 512 – 1024 kbps is available in a somewhat less reliable manner but this will be optimized (power back up systems, back-up providers, etc.) At the projects level the actual situation is more complex mainly due to their remote locations where the provision of electricity is not always assured nor of the desired specifications, Internet connections are not always fully respecting the contractually offered bandwidth nor are they always available in a predictable way. We demand special attention to this particular technical environment for the projects as we understand that different approaches could exist to provide the projects with the necessary information.

There are two different internet access scenarios for the projects : A) All projects do have a reliable Internet connection This scenario, which is for all clarity not the case today,

would involve probably private VSAT

connections, 3G, fiber optic, … connections. Considerations are: 

Financial feasibility of providing this Internet connectivity



Latency problems due to satellite links / 3G networks



Interruptions due to heavy rain (for VSAT connections), exceptional power outages etc…

We do not exclude this future scenario where all projects will be linked to the Internet but in that


21/33

scenario a maximum bandwidth between 256 – 1024 kbps has to be taken into account when proposing a software solution. B) All projects do have a link to the Internet but speed, quality and availability are not guaranteed This reflects fairly well the actual situation. Bandwidth varies between 64 kbps and 256 kbps, shared mode access, typically 4:1, the Internet service (provided by local providers) is not guaranteed 24/24 – 7/7.

Possible responses to the Internet connectivity problem for projects 

The proposed solution does take into account the (actual) situation described in B



The proposed solution only takes into account the (future) situation described in A. The minimum Internet bandwidth is to be specified by the candidate!



The proposed solution offers a migration path from situation B to A



There is no solution for situation A or B nor is there a solution for A and B

BTC can accept a solution where the periods without direct connection are solved by synchronizing the database in both ways, whenever a temporary Internet connection is available again (if that solution is a workable solution). More precisely this means that the locally stored application has the capability to work off line temporarily with locally stored data when no Internet connection is available. Having a standard technical solution (without major development) to cope with the specific online/offline connectivity problem explained above is clearly a competitive advantage. This solution should be described in terms of costs, benefits, risks, efficiency, feasibility and documented with representative references in the field. Clearly, the proposed solutions should exclude substantial specific customization / development efforts. BTC understands that typical transactional data, i.e. financial data demand a lower bandwidth than documents (typically 1 MB volume). An acceptable solution could be that, given lower available bandwidth, documents could be automatically downloaded/uploaded at night. Also if a solution proposes the use of local databases on the projects workstation (PC) the synchronization of these local databases could be executed at night.


22/33

Possible application configurations


23/33

II. BESCHRIJVING VAN DE GUNNINGSPROCEDURE Onderhavige opdracht voor de aanneming van diensten wordt gegund bij onderhandelingsprocedure met bekendmaking (zie artikel 26, §2, 3° van de Wet van 15 juni 2006 betreffende de overheidsopdrachten). De keuze van deze procedure wordt bepaald door het feit dat de aard van de dienst van die aard is dat de specificaties van de opdracht niet voldoende nauwkeurig kunnen bepaald worden om de opdracht volgens de procedure van aanbesteding of offerteaanvraag te gunnen. Inderdaad, gezien de complexiteit van de opdracht die dient gerealiseerd en de diversiteit aan functionaliteiten die dienen geleverd te worden, verwacht BTC dat de mededinging tussen de inschrijvers ruimte biedt voor een reflectieve benadering van de implementatie van de ERPfunctionaliteiten die dienen ontwikkeld en ingevoerd te worden, en dit zowel ten aanzien van de context als ten aanzien van het specifieke karakter van BTC. De gunningsprocedure verloopt in drie fases: 1) Eerste fase: toegangsrecht en selectie van de kandidaten Tijdens deze eerste fase zal BTC de door de kandidaten ingediende dossiers analyseren en ze vergelijken met de toegangscriteria en de kwalitatieve selectiecriteria. De toegangscriteria en de kwalitatieve selectiecriteria hebben betrekking op de persoonlijke situatie en de financiële capaciteit en technische bekwaamheid van de kandidaten (zie punt III infra). Er wordt een informatiesessie aangaande de selectiefase van kandidaten voorzien om het risico op formeel onregelmatige kandidaatstellingen te beperken (zie punt V infra). Elke kandidaat die niet wordt geselecteerd zal binnen een redelijke termijn een gedetailleerde onderbouwde beslissing ontvangen die de redenen voor niet-selectie vermeldt. 2) Tweede fase: verzending van het bijzonder bestek naar de geselecteerde kandidaten en ontvangst van de offertes In een tweede fase zal BTC minstens drie en maximum zeven geselecteerde kandidaten uitnodigen om een offerte in te dienen op basis van het bijzonder bestek dat BTC hen hiertoe heeft bezorgd. Het bijzonder bestek zal de gunningscriteria vermelden. 3) Derde fase: analyse van offertes en onderhandelingen BTC behoudt het recht, tijdens de derde fase, onderhandelingen te voeren met een of meerdere inschrijvers, die een substantieel regelmatige offerte hebben ingediend aangaande hun offertes. Na analyse van de offertes in vergelijking met de gunningscriteria die vastgesteld zijn in het bijzonder bestek en, indien nodig, na onderhandeling, krijgen de niet weerhouden inschrijvers binnen een redelijke termijn een gedetailleerde, onderbouwde beslissing met de redenen voor niet-selectie. Na verloop van een eventuele wachtperiode (standstill), wordt de overheidsopdracht gegund door de kennisgeving van de toewijzingsbeslissing aan de inschrijver met de offerte die als meest voordelige wordt beschouwd op grond van de gunningscriteria. Opmerking: BTC vestigt de aandacht op het feit dat er geen enkele verplichting bestaat voor de aanbestedende overheid om de opdracht toe te wijzen (cf. art. 35 van de wet van 15 juni 2006). De aanbestedende overheid kan afzien van de opdracht of de procedure opnieuw lanceren, indien nodig met andere modaliteiten.


24/33

III. TOEGANGSRECHT EN KWALITATIEVE SELECTIECRITERIA Indien twee of meer natuurlijke en/of rechtspersonen voor onderhavige opdracht samenwerken, dienen zij aan hun kandidaatdossier de overeenkomst van deze tijdelijke vennootschap en/of onderaanneming toe te voegen met vermelding van de verschillende betrokkenen partners. Indien de overeenkomst(en) van tijdelijke vennootschap en/of van onderaanneming zijn toegevoegd aan het kandidaatdossier, kunnen de vereisten aangaande de financiële capaciteit en de technische bekwaamheid bewezen worden door een of meerdere partner(s) of onderaannemer(s) van de kandidaat.

III.1 Toegangsrecht (Art. 61 e.v KB 15 juli 2011) Elke partner van de kandidaat moet voldoen aan de voorwaarden aangaande de persoonlijke situatie. De uitsluiting van een van de partners maakt de hele kandidaatstelling zonder waarde. Impliciete verklaring op eer Door het feit zelf van deelname aan deze procedure verklaart de kandidaat, evenals zijn eventuele partners, dat zij zich niet bevinden in een van de situaties van uitsluiting bedoeld in artikel 61 van het KB van 15 juli 2011.

Controle door BTC van de persoonlijke situatie van de kandidaten BTC dient de juistheid van de impliciete verklaring op eer voor de kandidaten nagaan alvorens de selectiebeslissing te nemen. Daartoe zal BTC aan de betrokken kandidaten vragen om zo snel mogelijk en binnen de gestelde termijn informatie of documenten te bezorgen die toestaan hun persoonlijke situatie na te gaan, en dit voor er enige beslissing is genomen omtrent de selectie. Er wordt dan ook aangeraden om de betrokken documenten (zie infra) indien mogelijk reeds bij het selectiedossier in te dienen. De inlichtingen of documenten die de BTC in staat stellen de persoonlijke toestand van de kandidaten of inschrijvers te onderzoeken, zullen door deze aanbestedende overheid zelf via elektronische middelen bij de gegevensbeheerders worden opgevraagd, indien deze via deze middelen kosteloos toegankelijk zijn.

Resultaten van het onderzoek In elk stadium van de gunningsprocedure kan een kandidaat uitgesloten worden van de overheidsopdracht indien tijdens de controle zou blijken dat de verklaring op eer niet overeenstemt met de persoonlijke situatie, of in voorkomend geval die van een van zijn partners. Een regularisatie achteraf is hoe dan ook niet mogelijk. Uitsluiting is ook mogelijk indien in de loop van de procedure zou blijken dat de persoonlijke situatie van de kandidaat, of, in voorkomend geval, een van zijn partners, niet meer overeenstemt met de verklaring op eer. Betreffende het bewijs dat de inschrijvers hun verplichtingen hebben vervuld wat de sociale zekerheidsbijdragen betreft: -

de inschrijvers die personeel tewerkstellen dat onderworpen is aan de Belgische sociale zekerheidsregeling moeten geen R.S.Z.-attest bij hun offerte voegen. Hun toestand zal rechtstreeks door de aanbestedende overheid worden gecontroleerd;

-

de buitenlandse inschrijvers die personeel tewerkstellen dat niet is onderworpen aan de Belgische sociale zekerheidsregeling dienen aan hun offerte het bewijs te voegen dat zij hun


25/33

verplichtingen hebben vervuld overeenkomstig de wettelijke bepalingen van het land waar zij gevestigd zijn.

III.2 Financiële capaciteit (Art. 67 KB 15 juli 2011) De kandidaat voegt bij zijn kandidaatdossier een verklaring op eer met vermelding dat zijn omzet voor elk van de drie jaar die voorafgaan aan deze publicatie boven 2.000.000 € zbtw inbegrepen ligt. Indien er niet aan deze voorwaarde wordt voldaan, wordt de kandidaat niet geselecteerd.

III.3. Technische bekwaamheid (Art. 68 en 72 KB 15 juli 2011) Enkel kandidaten die beantwoorden aan de vereisten aangaande de persoonlijke en financiële situatie (punt III.1 en III.2 supra) worden onderworpen aan de analyse van de technische bekwaamheid. III.3.1. Ervaring en tools (40 punten) Aan de kandidaten wordt gevraagd om aan te geven in welke mate men over de nodige ervaring en tools (software) beschikt om deze opdracht te kunnen uitvoeren (geïmplementeerd tijdens de voorbije drie jaar), aan de hand van de vragenlijst in bijlage II. Ervaring dient te worden aangetoond in minstens 60 % van de opgegeven submodules. Hierbij moet uitdrukkelijk rekening gehouden worden met de mogelijke scenario’s (I.2.3), de technische context (I.2.4) en de nood aan integratie met bestaande en toekomstige systemen, zowel intern als bij haar partners. III. 3. 2. Referenties (30 punten) Kandidaten worden gevraagd om een beschrijving te geven van drie recente referentieprojecten (max. 5 pagina’s A4 per referentieproject) die deze ervaring aantonen, en die het best (kwalitatief) en het meest volledig (scope) beantwoorden aan de kenmerken die in de 

algemene werkingspricipes van het nieuwe IT system (cf. “I.2.1 The general operating principles”)



toekomstige software architectuur (cf. “I.2.2 The TO BE applications architecture”)



verschillende scenarios (cf. “I.2.3 Scenarios”)



technische context (cf. “I.2.4 The technical context”)

Elk van de drie referenties moet betrekking hebben op de implementatie van een enterprise transactioneel systeem die werd uitgevoerd in de 3 jaren voorafgaand aan deze publicatie. Hiermee wordt bedoeld dat het project dat als referentie wordt gegeven volledig geïmplementeerd is op het moment van de indiening van het kandidaatdossier. Elk van de referenties moet een bedrag van minimum 100.000 € zbtw en minimaal 100 eindgebruikers betreffen. III. 3. 3. Voorgesteld team (30 punten) Kandidaten worden gevraagd om een beschrijving te geven van de profielen en de bijhorende CV’s van het technische team dat het project zal uitvoeren, evenals van de back-ups bij vertrek of onbeschikbaarheid van deze personen. Het team moet minimum bestaan uit een project manager,


26/33

een functioneel profiel en een technisch profiel. Elk lid van het team en de back-ups moet over minimum drie jaar relevante ervaring beschikken, tweetalig Nederlands – Frans zijn en over een zeer goede kennis van het Engels beschikken. Kandidaten worden gevraagd aan te duiden of het eigen personeelsleden zijn dan wel ingehuurde krachten betreft. De kandidaat geeft dus een omschrijving op van het gedeelte van de opdracht dat hij desgevallend in onderaanneming aan een derde zal geven.

IV. SELECTIE VAN DE KANDIDATEN EN VERZENDEN VAN HET BIJZONDER BESTEK BTC zal minstens de drie beste geklasseerde kandidaten selecteren en maximum de zeven best geklasseerde kandidaten en hen uitnodigen om een offerte in te dienen op basis van het bijzonder bestek dat hen met dit doel zal toegestuurd worden. De niet-geselecteerde kandidaten zullen binnen een redelijker termijn een gedetailleerde onderbouwde beslissing ontvangen met de redenen voor niet-selectie.

V. INFORMATIESESSIE Er wordt een informatiesessie gepland over de selectiefase voor kandidaten op de hoofdzetel van BTC, Hoogstraat 147 te 1000 Brussel, op 13.08.2013 om 10h00. Deze vergadering zal tot doel hebben om deelnemers te informeren over de voorziene selectieregels voor deze opdracht om het risico op formeel onregelmatige kandidaatstellingen te beperken. Ondernemers die wensen deel te nemen aan deze informatiesessie moeten zich ten laatste op 09.08.2013 per email inschrijven bij Cédric DE BUEGER op het adres [email protected].

VI. DEADLINE EN WIJZE VAN KANDIDAATSTELLING Kandidaatstellingen worden ofwel per post verzonden, ofwel ingediend op de kantoren van BTC, Hoogstraat 147 te 1000 Brussel. Ze dienen ingediend te zijn ten laatste op donderdag 12.09.2013. Een kandidaatstelling wordt in twee exemplaren opgesteld (een origineel en een kopie) en ingediend in twee afzonderlijke gesloten omslagen ter attentie van dhr Cédric DE BUEGER met volgende vermelding op de omslag: Kandidaatstelling Opdracht voor de aanneming van diensten Bxl 1434: Implementatie van een enterprise transactioneel systeem - "ORIGINEEL" of "KOPIE" evenals de contactgegevens van de kandidaat. Een PDFversie wordt via e-mail gestuurd naar het adres [email protected].

VII. GOEDKEURING VAN HET KANDIDAATDOSSIER De kandidaatstelling dient samengesteld als volgt: 

Het getekend identificatieformulier van de kandidaat in bijlage I bij deze kandidatennota -

Indien twee of meer natuurlijke en/of rechtspersonen voor onderhavige opdracht samenwerken, dienen zij aan hun kandidaatdossier de overeenkomst van deze tijdelijke vennootschap en/of onderaanneming toe te voegen met vermelding van de verschillende betrokkenen partners.

-

Indien de inschrijver een rechtspersoon is met rechtspersoonlijkheid, dienen de documenten die de handtekeningbevoegdheid aantonen van de inschrijver(s) toegevoegd te worden (m.n. de statuten van de onderneming en het uittreksel van het Belgisch Staatsblad dat de handtekeningbevoegdheid aantoont). Indien de ondertekenaar handelt op basis van een mandaat, moet de volmacht tevens toegevoegd worden. In dat geval dient duidelijk te blijken uit de statuten en het uittreksel dat de mandataris beschikt over de nodige delegatie bevoegdheden.


27/33



De volgende documenten ter staving van de impliciete verklaring op eer (zie supra) m.b.t. het toegangsrecht kunnen ook al bij de kandidaatstelling worden ingediend :



Getuigschrift dat de (buitenlandse) kandidaat in orde is met het betalen van sociale zekerheidsbijdragen



een beschrijving te geven van de profielen, de taken en de bijhorende CV’s van de leden die het hele project zullen uitvoeren, evenals van de back-ups bij vertrek of onbeschikbaarheid van deze personen. Het team dient ten minste te beschikken over de volgende profielen :



Het deel van de opdracht dat de kandidaat desgevallend in onderaanneming zal geven



De verklaring op eer waaruit blijkt dat de totale omzet van de kandidaat voor elk van de drie jaar die voorafgaan aan deze publicatie boven 2.000.000€ btw inbegrepen ligt;



De ingevulde Vragenlijst i.v.m. de relevante ervaring en tools (bijlage II);



Een presentatienota van drie referentieprojecten (maximum vijf A4-pagina's per referentieproject);


28/33

VIII. INDIENINGSTERMIJN VAN DE INFORMATIEAANVRAGEN Tot en met 30.08.2013 kunnen de kandidaten hun opmerkingen of vragen over deze nota sturen naar het volgende e-mailadres [email protected]. Als dat nodig blijkt, zal BTC al deze vragen verzamelen en er een antwoord op geven door een rechtzetting te publiceren via de officiële kanalen


29/33

BIJLAGE I : IDENTIFICATIEFORMULIER Firmanaam: Rechtsvorm: Maatschappelijke zetel (adres): Vertegenwoordigd door ondergetekende Naam, voornaam: Hoedanigheid: Contactpersoon: Telefoonnummer: Faxnummer: E-mail: RSZ-inschrijvingsnummer of equivalent: Ondernemingsnummer: Rekeningnummer voor de betalingen: Financiële instelling: Op naam van:

Gedaan te ………………….……………, op …………………….

Handtekening/naam:

………………………………………………


30/33

BIJLAGE II : VRAGENLIJST I.V.M. ERVARING

1) De kandidaat dient hieronder aan te geven welke tools hij reeds heeft ontwikkeld en geïmplementeerd gedurende de laatste 3 jaren en kort het betrokken project te beschrijven (jaar en opdrachtgever). Met het oog zijn selectie dient de kandidaat aan te tonen dat hij relevante ervaring heeft in de implementatie van minstens 60 % van de opgegeven sub-modules die meer gedetailleerd beschreven staan onder I.2. Human resources management HR Master Data (HR-01) Function description (HR-02) Recruitment & Selection (HR-03) Contract (HR-04) Payroll systems (HR-05) Availability and calendars (HR-06) Time sheet (HR07) Training (HR-08) Competence & evaluation (HR-09)

Financial management Budget creation & approval (BM-01) Budget reservation & follow-up (BM02) Forecasting (FT01) Bank accounts (FT02) Payments (FT-03) Financial accounting – General ledger (FIN-01) Financial accounting – Bank journals (FIN-02)


31/33

Financial accounting – Accounts Payable (FIN-03) Analytical accounting (ANA01)

Purchasing Vendor management (PUR-01) Public procurement (PUR-02) Tender database (PUR-03) Contracts (PUR04) Purchase order (PUR-05) Vendor evaluation (PUR-06) Purchasing / procurement (PUR07)

Logistics Inventory (LOG-01) Price management (LOG-02) Warehouse (LOG03)

Relationship management Partner relations (RM-01) Event management (RM-02) Case management (RM-03)


32/33

Project management

Project definition database (PM-01) Project WBS set up (PM-02) Project template management (PM03) Multi-project resource planning (PM-04) Gantt chart planning (PM-05) Risk/quality management (PM06) Project requirements planning (PM-07) Financial resource planning (PM-08) Critical path management (PM09) Project progress management (PM10)


33/33

Oproep tot kandidatuurstelling (aangepast op )

Recommend Documents