Overview
bitFit has a dedicated page to manage deployment cycles within the system. What is a “deployment cycle”? The deployment cycle is the period of time when an asset is deployed and then returned. We’ve named this page “Asset History,” where bitFit users can access specifics on when an asset was deployed, who it was deployed to, the anticipated initial return date, and the actual return if the asset has been brought back.
The difference between Assets and Consumables
Before we get into the deployment cycle details, it’s essential to understand the difference between Assets and Consumables.
Asset:
- Definition: An asset typically represents a single, tangible item or resource of value that an organization owns or uses. It could be a piece of equipment, a device, a vehicle, or any other physical item.
- Characteristics: Each asset is distinct and can be identified by a unique identifier (like a serial number).
- Maintenance: They may require maintenance, tracking of depreciation, and other lifecycle management.
Consumable:
- Definition: A consumable, on the other hand, is an item expected to be used up, depleted, or consumed over time. This includes supplies, materials, or items meant to be temporary and regularly replenished.
- Characteristics: They are usually measured in quantities.
- Maintenance: In most cases, Consumables are meant to be kept from being returned.
Each team establishes specific criteria to distinguish between Assets that deserve tracking and redeployment and Consumables that may not be worth the effort to retrieve. For instance, a common rule might be that if an item costs less than $500, it’s classified as a Consumable; however, if the cost exceeds $500, it’s considered an asset and requires tracking to ensure its return.
System Tools to Perform Deployments
In the Detail Card, users can find buttons linked to associated forms.
For instance, the Check Out button becomes available when an asset has the In-Stock status.
On the other hand, when an asset has the Deployed status, the Check In button becomes visible.
These buttons facilitate the “individual” deployment and return of assets. Consumables don’t have Check Out and Check In buttons in the Detail Card and can only be deployed and returned through the bulk pages.
How Does The Deployment Cycle Process Work, Technically?
When an asset’s status changes to “Deployed,” the system automatically generates a new Asset History record (opens a deployment cycle) with the following details:
- The deployed asset record is linked through a relation field, providing full access to the asset’s values, such as name, catalog details, serial number, etc.
- The user to whom an asset was given.
- The date of deployment.
- The location from which the asset was checked out. This value is taken from the deployed asset’s linked location.
- The quantity of deployed assets. If it’s an asset (Assets page), this value is always 1. However, the system also supports Consumables check-out and check-in, where users can specify the number of consumables given away and then returned returned.
- Lastly, the system automatically records how many times each asset was deployed. Each time the status changes to “Deployed,” the Deployment Counter value increments by 1.
Once the status changes to “In-Stock,” the system automatically updates the most recent linked Asset History record, concluding the deployment cycle with the following details:
- Check-in date
- User who performed the return (submitted the form in the system)
Since the system’s asset record represents a single physical asset in the real world, it’s straightforward for the system to identify the last deployment cycle and, therefore, choose the correct Asset History record. However, consumables have a different setup. That’s why, during bulk check-ins, the system prompts users to specify which deployment they’re updating in the check-in process.
